> Is it, that's not the impression I've gotten of the BSD's development, where is this shared upstream located ?

Not everything but there is OpenZFS, similiar for DTrace, e.g. DNS is unbound that is included, same for OpenSSL and stuff like that. Sure there are specific Unix tools that have their own implementation. The *BSDs also share code between them, so you have some OpenBSD and NetBSD code in FreeBSD and vice versa.

> No, but the components are written to take advantage of eachother and make use of the features of the underlying system, this is true for both systemd which makes direct use of Linux specific features, and the FreeBSD components which makes use of FreeBSD specific features like Jail.

Well there is a flag for jail processes in ps and a jail utility but that's about it. Everything else is pretty much BSD and POSIX, small and clean. Or what exactly do you mean?

> The FreeBSD devs only support the components they ship with, they offer no workarounds for anyone wanting to run something else, if you do you are on your own. I fail to see how this is in any way different when it comes to systemd dependency.

Not really. Most examples I gave are documented in the handbook and it's not really about supported but it's so simple that it comes down to deactivating something in rc.conf and activating something else. Most scripts are thoroughly documented and not much magic is happening. Like using Postfix instead of Sendmail. Some stuff is not officially supported like compiling base with LibreSSL that's worked on but you usually don't came across huge hurdles or complexity - and if so you can mostly figure it out.

> This will always be the case no matter what, whenever you change old patterns some people will not want to change, not anything wrong with that, it's just a fact of life.

I guess there is a fundamental difference in attitude. Change for the sake of change is frowned upon, there needs to be good reasoning and benefit in changing something.

Killing background processes after leaving the session by default or trying to prevent fork-bombs for all with some arbitrary task limit is something that is a behavoir change and would likely appear in bold in RELNOTES if ever adopted.

> I'm not overly fond of systemd, I think it's a step in the right direction, but I hardly think it's the 'ultimate solution', I fully expect it to be superceded by something better in the future, but of course that solution, whatever it is, will also suffer the same controversy as systemd has suffered now, it's just the nature of the game.

Some poeple looking for concepts that age well and don't need to be rewritten all the time, because this software stuff is complex. Here is snarky comment on that idea of throwing all away and rewriting it in Linux: https://www.jwz.org/doc/cadt.html for the results of that look here: https://www.jwz.org/blog/2015/04/i-told-you-so-again/

So it's opinionated and some people have a different opinion.

> Again, I don't agree with this conclusion, I don't think systemd is driving Linux users towards FreeBSD, to Gentoo perhaps

You're not an sysadmin or are you? There seems to some some odd split between sysadmins and other users of Linux. Deploying FreeBSD is much easier and less work as handling Gentoo. You can basically survive with regular freebsd-update and pkg update if don't do anything fancy.

> or any other Linux distro which provides the flexibility and support of components which systemd and FreeBSD does not.

Sure there are lots of alternatives - alpine, void linux.

I don't mind systemd - I think it's not exactly elegant but it solves real problems for a lot of people. I just think it's difficult to compare FreeBSD to systemd as you did.