There are various niche applications where Debian or any Linux are worse than FreeBSD.

For example the support for magnetic tapes and for a few other SCSI peripherals is better in FreeBSD. The Linux utility for controlling a LTO tape drive lacks some important options that the corresponding FreeBSD utility has.

I have a tape drive, and to be able to use it like I want I had to move it to a FreeBSD server.

Some years ago I was using a surveillance camera that was much easier to use in FreeBSD than in Linux, if you wanted to record good quality video and audio. I have not tried more recently to use such cameras in Linux, to see if now the recording quality is better.

So while there are more hardware devices that have better support in Linux than in FreeBSD, there are also devices with better support in FreeBSD than in Linux.

However the main reason why I use FreeBSD on many of my servers is that I need much less time for their administration than for Linux servers. In my experience, Linux servers need much less time for administration than Windows servers, and FreeBSD compares to Linux like Linux to Windows.

I have FreeBSD servers that I have not touched for years, and they have worked 24/7 with no downtime and no rebooting, and this includes servers connected directly to the Internet, which implement firewalls, routers and various services, like NTP, DNS servers and proxies, e-mail servers, web servers and proxies etc.

▲

adiabatichottub 2 days ago | parent | next [-]

> I have FreeBSD servers that I have not touched for years, and they have worked 24/7 with no downtime and no rebooting, and this includes servers connected directly to the Internet, which implement firewalls, routers and various services, like NTP, DNS servers and proxies, e-mail servers, web servers and proxies etc.

Same. We've got qmail config files with 2006 as the mtime

▲

gerdesj a day ago | parent [-]

"with no downtime and no rebooting"

So, no patching. I used to boast about my NetWare server uptimes but that is so noughties 8)

▲

adiabatichottub a day ago | parent [-]

Well, my experience on the stable release branches is that there aren't all that many kernel updates, so if you keep your services patched then you really only need to reboot about every 6 months.

▲

grahamjperrin a day ago | parent [-]

> … stable … about every 6 months.

Maybe slightly optimistic.

https://bokut.in/freebsd-patch-level-table/#stable/13

https://bokut.in/freebsd-patch-level-table/#stable/14

https://bokut.in/freebsd-patch-level-table/#stable/15

▲

AdieuToLogic a day ago | parent | next [-]

>> … stable … about every 6 months.

> Maybe slightly optimistic.

The longest without rebooting two prod FreeBSD servers I was once responsible for, including applying userland patches, was roughly 3000 days (just over 8 years).

	▲	blackhaz a day ago \| parent [-]
		My DigitalOcean FreeBSD droplet chugging along: 7:25AM up 1707 days, 15 hrs, 5 users, load averages: 0.30, 0.21, 0.17 Too bad they dropped support for it.

▲

adiabatichottub a day ago | parent | prev [-]

Fair, but to my point none of those security patches for 14.2 or 14.3 that required a reboot were critical for our use case. I'm more worried about people's crappy Wordpress blogs getting hacked.

	▲	gerdesj 7 hours ago \| parent [-]
		My approach to IT security starts from: There is very little security. That stands regardless of OS. I patch everything I can think of, as regularly as I can think of. It is rare that a patch is delivered along with a changelog along the lines of "meh, lol, soz" I'm old enough to remember when the notion of a patch was the only term in play, well before "service packs". I'm jolly boring and run host based firewalls and router, switch, edge etc firewalls, mostly with point to point rules. Its a bit of a faff and so is completely random and different passwords and targeted MFA on each host. I'm fairly sure it is quite hard to pivot across my land. The best approach to security is to start with: "Mine is a bit shite" and "I'm probably already compromised" and work from there. In the real world: start with a threat model and work on out. For most people that is avoiding scams and becoming part of a bitcoin farm.

▲

guenthert 18 hours ago | parent | prev | next [-]

> For example the support for magnetic tapes and for a few other SCSI peripherals is better in FreeBSD.

Could you give us another hint?

> The Linux utility for controlling a LTO tape drive lacks some important options that the corresponding FreeBSD utility has.

That should be easy to list, no? It's been a while since I used a LTO drive, but I don't know what I missed.

> I have FreeBSD servers that I have not touched for years

Are you sure, they are still "yours"?

▲

MarkusWandel a day ago | parent | prev | next [-]

Cameras? I suppose the world still has some weird cameras that need proprietary/weird drivers, but for all intents and purposes: USB cameras are UVC and work with a generic driver, and IP cameras are OnVIF and work with ffmpeg. I can't imagine the latter having any OS dependencies as far as Linux/BSD/Mac/Windows is concerned. Quality is fine - I have a bunch recording 24/7 with high quality audio and video.

▲

george916a a day ago | parent | prev | next [-]

Magnetic tapes? Super cool! What are you using them for if one may ask? Very curious.

	▲	Fnoord 17 hours ago \| parent [-]
		Standardization [1] for backups. A tape with 2.5 TB (uncompressed) goes for 30 EUR. The LTO-6 (affordable current iteration) drive itself goes for 300-500 EUR if you buy it second hand. Cheaper if you grab one without casing and FC, but you'd need a FC switch and a FC HBA. I went for a SAS HBA instead, although since I already for fiber through the whole house, FC would've been suffice. [1] https://github.com/LinearTapeFileSystem/ltfs

▲

irishcoffee 2 days ago | parent | prev | next [-]

> Some years ago I was using a surveillance camera that was much easier to use in FreeBSD than in Linux, if you wanted to record good quality video and audio. I have not tried more recently to use such cameras in Linux, to see if now the recording quality is better.

This example seems very hand-wavy. What camera?

▲

adrian_b 2 days ago | parent [-]

A Logitech FullHD camera on USB, but I doubt that the problem was camera-specific. I believe that I would have seen the same behavior on any high-resolution USB camera.

In FreeBSD, the command required for recording was very simple and it worked flawlessly. In Linux, it was more complex and there were various stuttering problems at maximum resolution. I am still using those cameras, but I have not tried them again in Linux. In Linux they worked worse than in FreeBSD around 5 years ago, perhaps nowadays there is no longer any problem in Linux.

This was intended to be an example that you cannot know a priori whether a given device will work better on FreeBSD or on Linux. In general, there is a greater probability for Linux to have good support than for FreeBSD, but there are also counterexamples, so you cannot be certain which is better until you try both.

▲

irishcoffee 2 days ago | parent [-]

I am sorry, I have a hard time accepting this level of detail, acknowledging it was half a decade ago.

In a nutshell, you content that FreeBSD running on the same hardware as "a linux" performed better with camera operations. However, you did not specify even a specific camera model, or the interface(s) used to interact with the camera.

I have zero issue accepting that a BSD is better than a linux at things, pretending otherwise is foolish. However, this specific example isn't tracking.

▲

adrian_b a day ago | parent [-]

I have already said that it was an USB camera, using the UVC protocol, and that it had FullHD resolution. Nothing else really matters about the interface.

FreeBSD has a dedicated service for USB cameras, webcamd, and it worked very well for capturing video and audio at maximum resolution, and without interference from any other programs that were running concurrently on the server. As I have said, in Linux not only the required configuration was more complex, but I tried several programs and all had stutter problems at FullHD resolution (while other programs were also running on the computer). That was the status at that time. Now, many kernel versions later, I assume that such problems no longer exist, at least not with old cameras.

I do not see what is not tracking for you in this example. It is not an isolated example, for many years FreeBSD was known to have less problems than Linux in handling video streams and audio streams with low latency and constant throughput. More recently, Linux has also improved, but in the past unreliable performance with certain video/audio devices was not unusual (i.e. where other programs running concurrently caused video/audio drops or delays).

▲

irishcoffee a day ago | parent [-]

That’s fair. I’m struggling to understand how Linux had a harder time interfacing with a USB byte stream than a bsd would. A model for the camera would be great!

	▲	adrian_b a day ago \| parent [-]
		I think that it was the Logitech C920, which is still available. But like I have said, I do not think that the model mattered much. IIRC the camera had an internal video encoder, because otherwise uncompressed FullHD video would not pass through USB 2.0. The differences between FreeBSD and Linux at that time were at 2 levels. Regarding the user interface, FreeBSD happened to include in the base system programs dedicated for using such a camera, so their use was very simple. On Linux I had to search and install a suitable package, and those that were available were more general video applications and because of that their configuration to do the specific thing that I needed was more complex. Besides the simpler interface, there was the stuttering problem on Linux, which was caused by the scheduling policies of the kernel. Perhaps it would have been possible on Linux to find a way to ensure a higher priority for the video and audio handling, to not be preempted by the concurrent programs running on the server, but since on FreeBSD everything worked fine out of the box there was no reason for me to investigate how that could be done on Linux.

▲

veegee a day ago | parent | prev [-]

[dead]