FreeBSD Can Now Be Built From Linux/macOS Hosts, Transition To Git Continues

[aht0]

If it was '3rd ever BSD install', well understandable.

Might be that with default 4.16 your RX gpu still doesn't work. That's why I was using 5.0 code for my Vega.

[skeevy420]

If it was '3rd ever BSD install', well understandable.

Might be that with default 4.16 your RX gpu still doesn't work. That's why I was using 5.0 code for my Vega.

And the first two were MidnightBSD . The third time I had to install FreeBSD twice because I didn't read the handbook close enough and didn't install root access .

I remember going in seeing the DRM version discrepancies and thinking that I'm gonna have a bad time and that I should wait a bit. Now that it's been a bit I've been meaning to get back to trying it again, only I'm holding out until OpenZFS leaves RC state and both Arch and FreeBSD have OpenZFS 2.0 available in some manner.

[aht0]

You 'll then have to wait for "13" (2021 March). 13 will switch to ZoL/ZoF codebase.
Least hassle for you.

[WorBlux]

Plenty, I'll list a few things it does better than Linux:

>In-kernel audio mixing, ie. lower latency than PulseAudio.
Everything is lower latency than PulseAudio, even the newer windows subsystems. Fortunately Pulse is largely userspace and other options exist where latency is critical

>It is the reference implementation of TCP/IP, its network stack performs better, and is used in networking research (eg. NETMAP).

Nice, but not generally a big selling point on desktop. And lacks the breadth or hardware support and depth of protocol support that Linux does. On both FreeBSD and Linux, optimal networking for a workload is often dependent on quite a bit of tuning as well.

>ZFS fully integrated into the kernel and various userland tools, working out of the box.

Which is awesome, if I want to dedicate a box to storage, but I don't always want that.

>Excellent documentation.

Nice but not unique. Arch, Debian, and Gentoo have fairly strong doc as well.

>Strong binary compatibility within each major release, including within the kernel.

It has it's advantages and disadvantages. It's not straight out better.

>It is an operating system that DOESN'T UNNECESSARILY CHANGE, ie. no re-learning everything all the time like on Linux, your skills are preserved.

Define necessary. Yes it stays very close to POSIX, which is again a mixed bag.

>No systemd.

Ouch... While systemd isn't the greatest, sys V was long overdue for a replacement, and systemd can be a pretty powerful tool in the right situation.

>pkg is significantly faster than apt/yum (at least in my experience).
>The ports system is so good it was widely copied by eg. Gentoo.
Ya, I really like gentoo's portage, and it was inspired by ports, but not copied, the aformention binary compatibility issues means it's got a bigger problem to solve. But unless you want to do something really weird a good package manager is nice, but not necessarily the deal maker/breaker.

>A system that was designed and engineered, not hacked.
Also a mixed bag, (Cathedral vs. Bazaar). And sometimes "right now" is overrules the "exactly right"

>Beautiful, clear source code.
Define Beauty. I can call a 30 year old rusted out pickup truck beautiful because of it's versatility and history, and laugh at Lambo style sports cars for their impracticality anywhere other than a track or car show. Clarity is more objective, but again there are trade-offs.

>Otherwise:
>NVidia always supported FreeBSD.

But always in their sort of "lob the binary over the fence" and "protect my trade secrets" style. It's nice that their drivers share enough code to make this possible, but the recent Linux conflicts shows that the approach also has trade-offs.

>Wine works well, and many Linux binaries run.
These are nice as fallbacks, but not really reliable enough to be plan A. Fortunately source compatibility is quite high for anything that cares to try.

In some ways Linux was/is the one behind, eg. Linux's eventfd/timerfd were playing catchup to FreeBSD's kqueue added in 1994.
>Absolutely, and especially since there's different license compatibility, some features will land first in FreeBSD and if you really like those feature FreeBSD is the right choice.

It is said, the mediocre developers go to Linux, but the best of the best go to BSD .
>People say a lot of thing to aggrandize themselves and their groups, but it's usually just mere wind or other puffery.

[aht0]

>In-kernel audio mixing, ie. lower latency than PulseAudio.
Everything is lower latency than PulseAudio, even the newer windows subsystems. Fortunately Pulse is largely userspace and other options exist where latency is critical

Fail to grasp your chain of logic. Namely Pulse being in userspace is the main cause of the latencies. Layers piled on top of layers.

>It is the reference implementation of TCP/IP, its network stack performs better, and is used in networking research (eg. NETMAP).

They claim it doesn't. Otherwise they'd be using Linux. Since their use-case is on the side of extreme bleeding edge, at speeds most users never try to achieve - most likely they do know better than you do.
What I've read from their tech blog and posts of employees in various places in Net, they backfeed most of their changes back FreeBSD upstream, excepting some things FreeBSD devs considered either "hacky" or just not fitting with "average use case" (larger mbufs, etc). I happened to read in some reddit post written by Netflix employee that while they gradually made it to 200GB/s encrypted TLS on FreeBSD, they didn't get even close to there using Linux (might recall wrong but number might have been around 140GB/s).

Nice, but not generally a big selling point on desktop. And lacks the breadth or hardware support and depth of protocol support that Linux does. On both FreeBSD and Linux, optimal networking for a workload is often dependent on quite a bit of tuning as well.

FreeBSD supports about 90% of hardware in wider consumer circulation. Sometimes stuff Linux gets in trouble with (got one weird laptop with OpenChrome iGPU).

https://forums.freebsd.org/threads/hardware-support-in-freebsd-is-not-so-bad-over-90-of-popular-hardware-is-supported.76466/

>ZFS fully integrated into the kernel and various userland tools, working out of the box.
Which is awesome, if I want to dedicate a box to storage, but I don't always want that.

Uhm, do you really think ZFS is only good for dedicated storage box use-case and not for general purpose PC? Really?

>Excellent documentation.
Nice but not unique. Arch, Debian, and Gentoo have fairly strong doc as well.

Linux docs don't come even close, unless somebody keeps track and updates each and every change religiously. Look at 10 years old HOWTO's. Next to worthless since so much has changed meanwhile, often for the sake of change itself. You either have to puzzle things out for yourself or hope somebody else have messed with it in advance of you. You cannot rely on write-up of a dude who did that exact thing 10 years earlier you would like to do now.

>Strong binary compatibility within each major release, including within the kernel.
It has it's advantages and disadvantages. It's not straight out better.

Why? It takes up very few extra resources and gives backwards compatibility up to FreeBSD 3.2-RELEASE (~1999). Can you still run legacy Linux 2.2 binaries if need be? Excepting the ones statically compiled.

>It is an operating system that DOESN'T UNNECESSARILY CHANGE, ie. no re-learning everything all the time like on Linux, your skills are preserved.
Define necessary. Yes it stays very close to POSIX, which is again a mixed bag.

Linux is characterized by "change for the sake of change". Often unneeded, when devs discard yet again some fine-working piece of software to pursue their own interests, replacing it with half-broken WIP - which users will have to put up with unless agree like to maintain older version themselves.

And POSIX is "bad" why. I still haven't gotten around that thinking process. Unified standards promoting compatibility between operating systems are "bad"?

>No systemd.
Ouch... While systemd isn't the greatest, sys V was long overdue for a replacement, and systemd can be a pretty powerful tool in the right situation.

FreeBSD does not use fucking sysV. It's using mewburn RC init - which is perfectly workable solution you can set up service management on top of, using tools available on ports. It also has huge library of standard shell script functions you can use for creating your own scripts rather easily. It does not have issues sysV init had.

systemd in my eyes is characterized by it's resultant constant breakage and bible-like manuals..

>pkg is significantly faster than apt/yum (at least in my experience).
>The ports system is so good it was widely copied by eg. Gentoo.
Ya, I really like gentoo's portage, and it was inspired by ports, but not copied, the aformention binary compatibility issues means it's got a bigger problem to solve. But unless you want to do something really weird a good package manager is nice, but not necessarily the deal maker/breaker.

Just love apt dependency hells, eh?

>A system that was designed and engineered, not hacked.
Also a mixed bag, (Cathedral vs. Bazaar). And sometimes "right now" is overrules the "exactly right"

So, your personal car is jury-rigged from 6 different cars, with electronics taken from tractor. And home is built from materiel taken from half dozen other razed buildings. As opposed to constructing something with clear goals.

>Beautiful, clear source code.
Define Beauty. I can call a 30 year old rusted out pickup truck beautiful because of it's versatility and history, and laugh at Lambo style sports cars for their impracticality anywhere other than a track or car show. Clarity is more objective, but again there are trade-offs.

I'll add layers on top of layers of frameworks in distros driving their configuration utilities. Something can't be handled by configuration utility - wanna dig under the hood and edit config files? GL. With each distro and even new version, start re-learning things. You got time for this? I don't.

>Otherwise:
>NVidia always supported FreeBSD.
But always in their sort of "lob the binary over the fence" and "protect my trade secrets" style. It's nice that their drivers share enough code to make this possible, but the recent Linux conflicts shows that the approach also has trade-offs.

Only Marxist, liberal or social democrat thinks that if somebody has done lots of work, they should be able to reap the results of his/her/it efforts for free even if the worker doesn't want to give it away.. Recent Linux conflict with Nvidia only shows that kernel devs can screw with you on purpose. They don't like something you do ideologically - they start trying to stop you.

>Wine works well, and many Linux binaries run.
These are nice as fallbacks, but not really reliable enough to be plan A. Fortunately source compatibility is quite high for anything that cares to try.

For gaming there is only Windows, Linux really lacks in that department outside indie games, Valve titles and occasional single player title.
Most opensource software have BSD variants. Commercial software - hell, I rather use Windows.

In some ways Linux was/is the one behind, eg. Linux's eventfd/timerfd were playing catchup to FreeBSD's kqueue added in 1994.
>Absolutely, and especially since there's different license compatibility, some features will land first in FreeBSD and if you really like those feature FreeBSD is the right choice.
It is said, the mediocre developers go to Linux, but the best of the best go to BSD .
>People say a lot of thing to aggrandize themselves and their groups, but it's usually just mere wind or other puffery.

I figure FreeBSD is roughly where Linux used to be before it got itself cursed with systemd.

[ssokolow]

Why? It takes up very few extra resources and gives backwards compatibility up to FreeBSD 3.2-RELEASE (~1999). Can you still run legacy Linux 2.2 binaries if need be? Excepting the ones statically compiled.

While OpenBSD is worse, FreeBSD isn't perfect in that respect.

(It's a link to the Rust issue tracker discussion of how to deal with BSDs breaking APIs between major versions when the Rust standard library needs to link to them. The issue is still open.)

[aht0]

While OpenBSD is worse, FreeBSD isn't perfect in that respect.

(It's a link to the Rust issue tracker discussion of how to deal with BSDs breaking APIs between major versions when the Rust standard library needs to link to them. The issue is still open.)

Rather looks like a problem of Rust itself lacking a concept of a versioned target.

You can probably get around the issue by running fitting version of an older FreeBSD in a jail/chroot along with your problematic Rust binary. It'd be using host's own newer kernel but "older FreeBSD" jailed inside "newer FreeBSD release" is supported. Vice versa isn't.

[ssokolow]

Rather looks like a problem of Rust itself lacking a concept of a versioned target.

You can probably get around the issue by running fitting version of an older FreeBSD in a jail/chroot along with your problematic Rust binary. It'd be using host's own newer kernel but "older FreeBSD" jailed inside "newer FreeBSD release" is supported. Vice versa isn't.

Versioned targets are one of the options under consideration, but it would complicate things and make supporting FreeBSD significantly more resource-intensive when they inherited and expanded upon Firefox's "run a mind-bogglingly massive unit test suite on every push before accepting it into master" development process. (Heck, when they're discussing extending the language, one of the tools they rely on is a bot named Crater which is capable of running the unit test suites of every single project on crates.io and GitHub against the changed compiler/stdlib... though they do try to minimize the number of times they do that. The CI bill Microsoft currently foots for them is already massive enough as-is.)

[aht0]

Versioned targets are one of the options under consideration, but it would complicate things and make supporting FreeBSD significantly more resource-intensive when they inherited and expanded upon Firefox's "run a mind-bogglingly massive unit test suite on every push before accepting it into master" development process. (Heck, when they're discussing extending the language, one of the tools they rely on is a bot named Crater which is capable of running the unit test suites of every single project on crates.io and GitHub against the changed compiler/stdlib... though they do try to minimize the number of times they do that. The CI bill Microsoft currently foots for them is already massive enough as-is.)

Correct me if I have understood it wrong but FreeBSD support alone wouldnt be benefitting. Android for that matter would be one, am I wrong?

[ssokolow]

Correct me if I have understood it wrong but FreeBSD support alone wouldnt be benefitting. Android for that matter would be one, am I wrong?

It's been a long time since I read some parts of that thread, so I might be misremembering, but, from what I remember, it's not the support for versioned targets that directly that's the problem, but their reluctance to commit to adding that many new profiles to their CI test suite for a single OS when it's already the bottleneck for getting commits into master.