Now i get it. I mixed it up with "windows type single threaded" where, even if you had a multiple processor machine, windows will run only on one processor.

Interesting, from that links i see some replies like this:

> Also, the FreeBSD license was more relaxed and commercial products (like NetAPP) could include and extend FreeBSD without disclosing their modifications.

and then (same comment):

> Our frustration with lack of support for FreeBSD moved us to choose Linux and Windows

I think these two things are strongly correlated: the bsd license allow companies to avoid contributing back improvements, and this prevents the main FreeBSD codebase from getting better.

I think that in the long run this is detrimental to projects.

In the very beginning I think they(df) used pgbench kind of benchmarks 'the smp' benchmark, as a lot of people were using postgres and was really easy to compare qps and transactions per second, of course it also tests ufs2 vs hammer. (if I remember correctly)

It was a long time ago, but freebsd5 felt more like a new OS than just a 4.11->5.0 bump, particularly with the removal of the giant lock and all the witness(4) work, took a while to figure out how to finetune it as a lot of systems were giant free but not all, and also of course moving one lock to many small locks means a lot of spinning and certain patterns of workloads are slower than before. It took until 7.0 to get amazing, and then in 8 or so I think it was super solid.

Dragonfly went with kernel messaging and one scheduler per core, and FreeBSD spent a lot of time into making a preemptive scheduler (sched_ule (4) : http://fxr.watson.org/fxr/source/kern/sched_ule.c?v=FREEBSD-...)

Weird times, but I am super grateful that both the FreeBSD team and the DragonflyBSD team did what they think is right.

Mad respect to the people who are just coding what they think is right.

> But the reality is, nearly no one even does comprehensive OS benchmarking anymore - so there isn't really a good alternative source to use.

Imho benchmarks only get you so far.

If yu are any kind of serious about performance you should do your own testing and benchmarking. Benchmarks from other people should only help you selecting candidates platforms on which to run your own benchmarks.

Yes, I also have same hard time believing in it, but internet felt snappier.

The issue is that you're performing a test which involves a whole bunch of interconnected layers and then assigning one part of that interconnected system as where the benefits lie.

Why not the TLS implementation? The video drivers and their kernel interfaces? The OS' process scheduling? A dozen other things that might be responsible for the perceived performance difference to one degree or another?

It feels like gamers who blame 90% of multiplayer issues on "the netcode".

It'd be different with data looking specifically at TCP connection establishment timing without a bunch of other stuff involved.

UFS without soft updates is easily susceptible to corruption.

The "soft updates" option must be chosen when the disk is formatted for good reliability.

As I have said, 20 years ago "soft updates" in UFS worked better than journaling in the other contemporaneous file systems.

Nowadays it is likely that this is no longer true. I am still using FreeBSD in servers, but unlike 20 years ago I can afford UPSes so I no longer see often crashes due to power outages, even if I had one incident some time ago with a battery that had not been replaced yet after the UPS had warned that this is necessary, and when a power outage happened, the UPS worked for less than a minute and the power was cut before system shutdown. Even in this case there was no file system corruption on UFS.

Even with this good recent experience, today I would no longer trust UFS like 20 years ago, because it is said the current FreeBSD maintainers no longer understand the convoluted code that implements "soft updates" in UFS, and in any case most of their file system maintenance and development work is directed at ZFS now.

ZFS had its own data corruption bug some months ago. TBH, this was a big minus. You really don't expect such things from a filesystem which is in production for years and whos aim is data integrity. Now, to its defence, it is only used by FreeBSD and some nishe linux distributions, so it does not get much testing.

20 years ago is 2004, not the 90s. I don't know, but it's certainly possible that one of them was in the lead in 1995, a different one in 2005, and a different one in 2015. This is especially plausible because Linux was only created in the mid 90s, so those first few years seem likely to have been disproportionately rough.

NTFS might have been rock reliable in Windows NT and perhaps also in Windows 2000.

When Windows XP has been launched, NTFS was certainly much less reliable. Even without being affected by any crashes or other anomalies, the free space on the NTFS partitions of early Windows XP computers would shrink steadily, without any apparent cause, requiring a reformatting/reinstallation after some time.

Early Windows XP was very buggy. While a computer with Windows XP did not require one or more reboots per day like one with Windows 98, failing to reboot it for more than a few days guaranteed a crash.

Only after installing several massive service packs in the following years, Windows XP has become reasonably stable.

For me, in the 90s ext2 was much, much reliable than ntfs. After a power failure ext2 will just run fsck and fix the filesystem while ntfs will sometimes give up.

> ISP in late 90s. NTFS was absolutely rock reliable, then

Well, i stayed away from NTFS in the Win2000 era because crashes would make your system unusable.