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

[aht0]

No, I use ZFS on linux for some of my storage. It's just that level of integration and "out of the box" support shines when storage is your first concern. When you also want to get a lot of other uses it kind of gets lost in the wash.

Duh, whatever. I guess integration is indeed meaningless when you don't give a fuck whether your system will be able to boot post some update..

The fact that bad documentation exists doesn't negate the good documentation that exists, and is regularly checked and updated.

That "good documentation" exists on exactly how many distros out of total number? And can be applied to how many other distros - which all use different utilities, folder paths and software versions.. Even versions of the same distro varie.

So if I go into best buy and pick 10 computers at random 9 will work? I don't think that's even true for Linux. Mobile devices are particularly hard. There are supported laptop devices out there but the chances you'll pick one up by happenstance aren't high.
Sure if I pick up a server or workstation it'll most likely work.

uhm, from PC's, my last 6 or so have worked with BSD without issues. Last issue I remember was GPU support of an Athlon 5350 - which was added ~ year after I got the system.

Laptops - keep some compatible WiFi cards in your drawer, swap out if need be and you are mostly good to go. Only other thing to watch out for is GPU support, might want to avoid hybrid GPU systems and see first if you can turn hybrid-gpu out and use machine with the CPU's iGPU alone. Not that different from how things used to be with Linux.

A mixed bag is not the same as bad. Yes it's a fixed stanardized interface, but it was developed over 50 years ago in a very differnt hardware enviroment and a very different set of constraints. Yes it's been updated, and is a great target for "infrastructure code", At lot of local maximums found, but in some cases finding the actually maximum requires jumping to a new area of the problem space.

Quoting yourself from below. Do get a clue please. Last iteration of POSIX is POSIX.1-2017.

Never said it did my friend. But it was what a lot of linux distro's were, and it was a problem. And if you are going to criticize the linux userspace for going every which way, you have to credit systemd for providing a fairly reasonable level consolidation of certain system-level tools. Sure there are bugs, but no software is perfect.

Why I can't I? Linux users seem to feel free and even obligated to make sneering appearance in every goddamn BSD-related news thread in here and criticize every aspect thinkable - since beginnings of the Phoronix.
I have really hard time giving systemd any credit. Most of the time I have touched systemd distros I've invariably found it making my life harder by running me into weird errors and making me spend shitload of time trying to figure out whats wrong. Then they are really good of shifting blame elsewhere - not our fault, not fixin. I rather go use minimalistic system I can expand if need be, rather than deal with monster that has to be "minimized" in order to be usable (disable malfunctioning components, find workarounds). Its waste of time.

Oh please get a clue. Why don't you go violate nVidia's copyrights and see if they worst they do to you is refuse to provide tech support and make it slightly harder to integrate your code with thiers? It was obvious to anyone that cared to pay attention that when linux started doing kernel modesetting that it was going to get harder and harder to properly integrate a closed BLOb. I have zero sympathy. In the meantime, any AMD device of the last 4 gens or intel device of the past 8 just work. (And that's true on the BSD's too

Lol. But Nvidia's copyrights are not the issue here. Issue is Linux devs finding certain aspects of Nvidia's practises unpalatable due ideological convictions and fucking them over about it. And users of Nvidia for that matter. It's not as Linux is losing money due Nvidia.

OS's aren't at the level of cars, they're at the level of cities, and you woudn't want a city built by only 6 builders.

Wrong. Most expensive and complicated portion of any modern car is not the mechanical aspects of it but onboard electronics and software. It forms about 70% of the price of any new car these days.

Yes, because that solution generally works everywhere, is easily scripted and replicated, and usually well described by the man utility. If I'm not doing it enough for it to be in muscle memory, I'd rather have it written down, and if it's not a trivial enough lever to be found with a simple in WM search, fincdng, installing a learning a specific config app will likely eat up as much time as skimming the man file. But all this is just as true in one of the DE's running on a BSD as it is linux.

[/QUOTE]
Good luck. You dont seem to have had an issue where same configuration utility simply writes your configuration file OVER again with its own data, erasing your modifications it deems incorrect. Then, trying to remove said configuration utility to prevent it from happening may lead to rather slippery road of borked OS.

[WorBlux]

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

No, I use ZFS on linux for some of my storage. It's just that level of integration and "out of the box" support shines when storage is your first concern. When you also want to get a lot of other uses it kind of gets lost in the wash.

Look at 10 years old HOWTO's.

The fact that bad documentation exists doesn't negate the good documentation that exists, and is regularly checked and updated.

FreeBSD supports about 90% of hardware

So if I go into best buy and pick 10 computers at random 9 will work? I don't think that's even true for Linux. Mobile devices are particularly hard. There are supported laptop devices out there but the chances you'll pick one up by happenstance aren't high.

Sure if I pick up a server or workstation it'll most likely work.

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

A mixed bag is not the same as bad. Yes it's a fixed stanardized interface, but it was developed over 50 years ago in a very differnt hardware enviroment and a very different set of constraints. Yes it's been updated, and is a great target for "infrastructure code", At lot of local maximums found, but in some cases finding the actually maximum requires jumping to a new area of the problem space.

FreeBSD does not use fucking sysV.

Never said it did my friend. But it was what a lot of linux distro's were, and it was a problem. And if you are going to criticize the linux userspace for going every which way, you have to credit systemd for providing a fairly reasonable level consolidation of certain system-level tools. Sure there are bugs, but no software is perfect.

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.

Oh please get a clue. Why don't you go violate nVidia's copyrights and see if they worst they do to you is refuse to provide tech support and make it slightly harder to integrate your code with thiers? It was obvious to anyone that cared to pay attention that when linux started doing kernel modesetting that it was going to get harder and harder to properly integrate a closed BLOb. I have zero sympathy. In the meantime, any AMD device of the last 4 gens or intel device of the past 8 just work. (And that's true on the BSD's too

Open source has a strong business and market case.

So, your personal car is jury-rigged from 6 different cars,

OS's aren't at the level of cars, they're at the level of cities, and you woudn't want a city built by only 6 builders.

Something can't be handled by configuration utility - wanna dig under the hood and edit config files?

Yes, because that solution generally works everywhere, is easily scripted and replicated, and usually well described by the man utility. If I'm not doing it enough for it to be in muscle memory, I'd rather have it written down, and if it's not a trivial enough lever to be found with a simple in WM search, fincdng, installing a learning a specific config app will likely eat up as much time as skimming the man file. But all this is just as true in one of the DE's running on a BSD as it is linux.

[WorBlux]

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.

Anything I put in paragraph after a ">" was a quote of dacha, https://www.phoronix.com/forums/member/32615-dacha , not my statements

Sorry for the confusion.

[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.

[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]

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]

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]

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]

>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.

[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.