FreeBSD Working On Support For LinuxBoot, Going From 256 To 1024 CPU Core Limit

[kpedersen]

2010 was a long time ago. That's not to say you're wrong about how it was back then, but, that was back then. My comment implied that today, the BSDs are having a harder time keeping up.

I get that but what I was generally suggesting was that although in 2010 Windows had vastly superior hardware compatibility than Linux, it didn't make much of a difference. People still could easily use the better operating system if they wanted. Hardware support is ultimately a non-issue when you can simply buy supported hardware. I don't feel this has changed at all since 2010 and will still be the case in space-year 2499.

In short, I find it bizarre that someone would grab some bargain bin PC and limit themselves to a crap OS, just because they are too lazy to replace the hardware. The (invalid) argument is that they cannot afford compatible hardware... but this is wrong, because older cheaper hardware *is* the compatible hardware

[uid313]

And Linux should adopt ZFS and DTrace and become new Unix. Ehm, wait, it's never going to happen due to "not invented here" syndrome right? Honestly after Solaris demise I'm glad there is some OS supporting ZFS and DTrace as a Solaris legacy. Unfortunately various Ilumos forks do not have critical mass, at least from my point of view. FreeBSD looks most stable from user-base point of view...

Linux already have some ZFS support using the OpenZFS, plus other file systems such as ext4, XFS, Btrfs, and Bcachefs. ZFS is problematic due to its license.

Linux already have support for DTrace, and also have support for eBPF, SystemTap, ftrace, ltrace, strrace, and LTTng.

Linux doesn't have any "not invented here" syndrome, which is why Linux have support for DTrace from Solaris.

[schmidtbag]

I get that but what I was generally suggesting was that although in 2010 Windows had vastly superior hardware compatibility than Linux, it didn't make much of a difference. People still could easily use the better operating system if they wanted. Hardware support is ultimately a non-issue when you can simply buy supported hardware. I don't feel this has changed at all since 2010 and will still be the case in space-year 2499.

I get what you're trying to say but I don't really agree. In the context of what the BSDs are usually run on, it's typically headless servers. In particular, not ones that depend on add-on accelerators; I don't really hear about BSD being used for AI or GPU compute (though I'm sure it does happen). So, all they really have to concern about is NICs, storage devices, and CPUs. In 2010, we didn't really see much software optimized for advanced CPU instructions, for any OS. That's one of the reasons why distros like Gentoo got popular, because it allowed people to squeeze more performance out of their existing hardware when nobody else bothered to optimize anything. CPU schedulers were relatively basic since the CPUs themselves were relatively basic (SMT from Intel and Oracle's SPARC were the only real complexities). So - once you attained basic compatibility and functionality, it didn't take much for BSD to really hone in on optimizations, because there just wasn't that much to optimize. But nowadays, we're seeing network devices with new protocols, we're seeing new secondary accelerators (like ASICs, VPUs, tensor units, etc), and we're seeing CPUs with a mashup of different core configurations with a slew of advanced instructions that require a kernel to be compatible. We see Linux get huge patches from companies like Intel, AMD, IBM, Google, etc for hardware-specific purposes, but how much of that finds its way to BSD? Linux sees regular updates to CPU schedulers, but how often do the BSDs get the same treatment? This is the current problem with the BSDs - things are rapidly getting complex with all architectures, where even though the BSDs should run, they're not likely to offer any performance advantage.

The (invalid) argument is that they cannot afford compatible hardware... but this is wrong, because older cheaper hardware *is* the compatible hardware

I don't see that as an invalid argument. It doesn't make sense to run an organization by buying new old-stock hardware, especially considering how rapidly it is evolving lately. That hardware is cheaper because it isn't desirable.

[oiaohm]

Really we are looking at this wrong. *Every* OS should use a "standard" compat layer so any driver written can be used by any OS implementing that layer. But of course that is some serious engineering that the industry simply doesn't have the skills for anymore.

It does not workout. There was attempt with Linux freebsd and unix back in the 1990s. Everyone end up giving up on the idea. The problem is that you end up with code that is not optimal and does not perform well.

This is not a case of not having serious engineering this is a case that the OS cores are too far different from each other that any attempt at compat layer ends up comprising performance and memory usage.

[dragorth]

2010 was a long time ago. That's not to say you're wrong about how it was back then, but, that was back then. My comment implied that today, the BSDs are having a harder time keeping up.
For what it's worth, it is still relevant, but the relevance is gradually diminishing.

Relevant for what, exactly? Commercial usage of FreeBSD has Netflix and TrueNas Core, while the consumer usage of FreeBSD has the PS4 and PS5 as a flagship. Considering Sony just announced it had sold 40 million PS5s, not including the PS4, I would call that very successful.

If you are talking about Desktop, then even Linux hasn't cracked that nut, so why are you complaining FreeBSD hasn't?

[schmidtbag]

Relevant for what, exactly? Commercial usage of FreeBSD has Netflix and TrueNas Core, while the consumer usage of FreeBSD has the PS4 and PS5 as a flagship. Considering Sony just announced it had sold 40 million PS5s, not including the PS4, I would call that very successful.

I said BSD is losing relevance, not that it is irrelevant. Currently, it still has a viable market, but I don't see that being the case for long if they don't keep up. In each of your examples, the OS isn't doing anything that another OS couldn't do equally as well.

If you are talking about Desktop, then even Linux hasn't cracked that nut, so why are you complaining FreeBSD hasn't?

I wasn't talking about Desktop, but even if I were: while Linux isn't a popular desktop choice, it is far more usable for today's hardware and software.

[kpedersen]

But nowadays, we're seeing network devices with new protocols, we're seeing new secondary accelerators (like ASICs, VPUs, tensor units, etc), and we're seeing CPUs with a mashup of different core configurations with a slew of advanced instructions that require a kernel to be compatible.

For regular hardware buyers, this doesn't affect them. They don't use things like this.

For businesses, they will basically go with whatever the hardware vendor tells them to go with.

We see Linux get huge patches from companies like Intel, AMD, IBM, Google, etc for hardware-specific purposes, but how much of that finds its way to BSD?

A good amount to be fair. More than Apple and Windows kernels get if you consider some of the shims/compat layers. Plus FreeBSD has its own source of company contributions via Netflix relating to the network stack.

I don't see that as an invalid argument. It doesn't make sense to run an organization by buying new old-stock hardware, especially considering how rapidly it is evolving lately. That hardware is cheaper because it isn't desirable.

Companies buy Windows. They will not run a fleet of Linux workstations either. Once that changes, then perhaps this argument might become more relevant for people wanting cheap ex-business surplus machines as their workstation.