Just a little push for FreeBSD

Just made the attached post in a Facebook IT group. Think I will be getting on the Linux fanboys nerves yet?

Still, some might relent and join our ranks.
 

Attachments

  • Screenshot_20220127_183219.png
    Screenshot_20220127_183219.png
    221.2 KB · Views: 371
I dunno, I was considering it but I'm sticking with Linux on prod because I can issue an update command and get security patches without having to read UPDATING and discovering that a pkg default has changed and if I don't like it I have to build everything from ports.
 
I think you missed the part of my statement where I have to completely overhaul my updating scheme in order to do an update.
 
On a serious note though, I don't really see the big difference between updating packages on Linux and updating packages on FreeBSD. Actually compared to many Linux distros, I'd say the pkg system on FreeBSD is less stressful, more straightforward to use, breaks less often and offers more packages out of the box (maybe not more than Arch when including the AUR and NixOS, but more than many other distros). So I am not quite sure what Linux distro you are referring to.

As for system updates, there is a rollback functionality. And there are also zfs boot environments, though I have not used them, yet. But I'd assume they provide about as much security as the rollback mechanisms in the Linux world.
 
It has the same spirit as users from Linux to Windows.

If the rebels could succeed they would find that they had destroyed themselves. :-/
 
So I am not quite sure what Linux distro you are referring to
Like, literally any one that puts breaking changes in major releases and has separate versions of packages for those version number increases? Versus one system for (usually) only two major releases at one time that will issue breaking changes at any time and expect you to clean up the mess on update.

This isn't a troll, I use FreeBSD on my stuff every day, but unversioned ports sucks.
 
Like, literally any one that puts breaking changes in major releases and has separate versions of packages for those version number increases? Versus one system for (usually) only two major releases at one time that will issue breaking changes at any time and expect you to clean up the mess on update.

This isn't a troll, I use FreeBSD on my stuff every day, but unversioned ports sucks.
okay, let's make this more concrete. Please name a package and a distro where you see this happening in a better way vs. FreeBSD. Because right now it sounds a bit too much like abstract dissatisfaction ...
 
You mean that you get older and in this sense more stable packages when you are on Debian 9 "stretch" then on Debian 11 "bullseye"? It is true that FreeBSD pkgs, from what I understand, gives you fairly recent updates independently of the OS version, if you like to go latest, or quarterly updates if you like less risk. Now for me personally, coming from Arch Linux and NixOS, that has not been an issue. I'd say I was positively surprised by this. But then my use case is probably different.

One should note though that FreeBSD, in contrast to e.g. Arch Linux, provides multiple major versions of certain packages such as PostgreSQL, PHP, Python, Nodejs and similar things.

After a little research I found there was actually a thread on this issue some years ago here in this forum. So I'd say it is a thing for debate if you want to have versioning based on OS releases or not. For the time being FreeBSD has chosen, with certain reasons, to have package versions independent of OS releases. If you'd say that is unacceptable in production for you use case, well yes, you cannot run FreeBSD. Maybe something based on RHEL might be a better choice then.
 
The separation of core OS and additional packages is the best thing about *BSD. "Linux" is attempting similar via Snap/Flatpak and so on, the long-way-round solution... (not a good approach in my view).

If you want to find out how nuts an OS can get with experiment with GUIX, that allows complete craziness.

Regarding OP, and most users in this forum, stop looking at it like a competition and simply use what you like. It is possible to drive a Honda without hating a Nissan, for example.
 
Picking up on msplsh's posts here:

What Debian is doing is: Freeze versions of all software for a distribution release (with very few exceptions) and then backport security fixes to the older versions. While this sounds kind of nice in theory, there were more than enough problems (even concerning security!) with that in practice. While it's true you almost never chase incompatible changes as the admin of a Debian installation, you'll be confronted with packages broken in weird (and, sometimes unnoticed) ways. Well, some upstreams are truly fed up with Debian, I had a giggle reading e.g. this statement on rspamd's website:

Debian standard repos notes​

Please DO NOT use those packages.
Rspamd is also available in some versions of Debian and Ubuntu. Please DO NOT use those packages, as they are not supported in any way. Any issues or feature requests related to the packages from Debian provided distros will be closed with no feedback (or even rage feedback). Just don’t do it, you are warned!

1. Use STABLE branch of packages: those packages are the official rspamd releases which are recommended for production usage.

2. Use EXPERIMENTAL branch of packages: these packages are less stable and they are generated frequently from the current development branch. Experimental packages usually have more features but might be SOMETIMES broken in some points (nevertheless, bugs are usually quickly fixed after detection).

3. Use ASAN branch of packages: these are packages (both stable and experimental) designed to debug Rspamd issues, especially core files, using advanced debugging tools. Use these packages if you encounter an issue in Rspamd and you want it to be fixed.

FreeBSD ports/packages are "rolling release", and that's all you can have. Your only choice is to opt for quarterly snapshots if you want breaking changes not more often than every 3 months. Yes, looks like a bit more work for the admin, but IMHO, it's the sanest way to distribute 3rd-party software.

The huge advantage of a BSD system is: there actually is a base system (single project, well integrated). FreeBSD's base follows a strict release engineering, and that's completely independent of 3rd-party software distributed as ports/packages. This gives you the guarantee (very similar to Debian) that your base won't break. Still, you get up-to-date software to run on it.
 
backport security fixes to the older versions
Which is just what I want for production servers. At home, I'm fine with being like "uh, ok, I guess I'm updating to Postgresql 13 today" despite Postgres providing security patches four major releases back.

What Rspamd implicitly is saying is that Debian should be picking up the support for those packages, not them. Which is fine. Once you understand Debian's objective, it just gets into disagreements about timeframes.

stop looking at it like a competition and simply use what you like.

Essentially. I was just trying to point out that we shouldn't razz them because there are some things they do that make it better suited for task.
 
What Rspamd implicitly is saying is that Debian should be picking up the support for those packages, not them.
Uhm no, what they're saying (and this was stated more explicitly, not sure it's still online though) is that Debian's "official" packages are patched broken beyond repair. And having tried one of them, I can confirm that...
 
msplsh I am sorry to tell you, but FreeBSD does have PostgreSQL from versions 10 to 15 in pkgs: all the officially supported versions, just as you want to. Talking points like these make me wonder if you actually do have a point, you know?
 
Back
Top