>But mostly it's taken from a shared upstream with some specific patches.
Is it, that's not the impression I've gotten of the BSD's development, where is this shared upstream located ?
>Source lying in the same git repository is not tight coupling.
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.
>No one tells you what to do and most userland is pluggable
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.
>arbitrary new limits or changing default behavior or rewriting old tools in a manner that is disliked by some.
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.
>A lot of experienced devs and sysadmins also voiced conceptional and design complaints but I'm not able to judge that really. Some of it looks very reasonable.
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.
>TL;DR systemd is not just init - it changes Linux and causes fallout - FreeBSD was always popular and it's getting attractive for servers due to these changes.
Again, I don't agree with this conclusion, I don't think systemd is driving Linux users towards FreeBSD, to Gentoo perhaps or any other Linux distro which provides the flexibility and support of components which systemd and FreeBSD does not.
> 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.
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.
>Not everything but there is OpenZFS, similiar for DTrace, e.g. DNS is unbound that is included, same for OpenSSL and stuff like that.
Eeh ?
OpenZFS is not a BSD upstream project in any way shape or form, heck it did not even originate in the BSD's, it came from Solaris, same with DTrace.
Also AFAIK only FreeBSD of the BSD's support ZFS and DTrace ?
OpenSSL, same here, how is this a BSD upstream project in any shape or form ?
>The *BSDs also share code between them
Very little from what I can tell, unless you count projects which did not originate from one of the BSD's. Anything you can point me to ?
>but it's so simple that it comes down to deactivating something in rc.conf and activating something else.
Based upon your distro choice, this isn't harder in Linux either, nothing you need to venture over to FreeBSD for.
>Killing background processes after leaving the session by default...
Well there is quite a difference here as systemd as a project compared to FreeBSD does not ship binaries, they ship a tarball which is then configured, compiled and deployed by a distro, which in turn decides what options to use as default for their userbase.
Whatever default systemd chooses, it will be right for some and wrong for others, but each distro will most likely choose the option best suited for their userbase (or face complaints).
>there needs to be good reasoning and benefit in changing something.
But who decides what is 'good reasoning' ? That's just a nonsense statement, with practically any change, some people will think it's good reasoning, and some will think it's bad reasoning.
> OpenZFS, [...] OpenSSL is not a BSD upstream project in anyhow is this a BSD upstream project in any shape or form
Upstream as in it's included in the distribution but not primarily developed there. I thought that is the correct way to specify something that you use but that is from somewhere else? OpenZFS grew out of OpenSolaris and is now used from ZFS on Linux, illumos (SmartOS and others) and FreeBSD. Same fore DTrace.
> Very little from what I can tell, unless you count projects which did not originate from one of the BSD's. Anything you can point me to ?
Just a quick Ctrl+F on the release notes https://www.freebsd.org/releases/10.0R/relnotes.html#new - make from NetBSD, a driver from OpenBSD. I guess there is more flow for bugfixes and patches. It's not so uncommon afaik but I'm not sure.
> Based upon your distro choice, this isn't harder in Linux either, nothing you need to venture over to FreeBSD for.
I've never claimed that? It's hard for systemd components. It's also clear that Linux is clearly better fitted or the only choice for a lot of use cases due to hardware and software constrains. I don't mind Linux :)
> Well there is quite a difference here as systemd as a project compared to FreeBSD does not ship binaries, they ship a tarball which is then configured, compiled and deployed by a distro, which in turn decides what options to use as default for their userbase.
IMHO defaults matter a lot. Sure, I can also turn it off with a small edit but then I need to remember the machines where it's on or off and I'm often don't have root. The problems due to the task limit are also not so great and this is in Ubuntu 16.04: https://news.ycombinator.com/item?id=11675129
It's nice to have release notes that are reliable and and predictable behavior. It's a different attitude.
> Whatever default systemd chooses, it will be right for some and wrong for others, but each distro will most likely choose the option best suited for their userbase (or face complaints).
Yeah, not all agree with this approach. This is is totally understandable from the point of systemd as they want to move fast and get stuff done but usually that means that you don't know what to expect when you login somehwere - you basically have to lookup systemd defaults related to the distro release or worse patch-version. If you just want to deploy something and make it run stable and fast it's a PITA. Often you don't have control over the distribution.
> But who decides what is 'good reasoning' ? That's just a nonsense statement, with practically any change, some people will think it's good reasoning, and some will think it's bad reasoning.
How is this a nonsense statement? Philosophers thought about this for thousands of years, it's the foundation of science. How about something you are able to reason about easily that is fully understandable and easily to modify, composable and lacks hidden complexity and side effects?
Sure you'd write software for nuclear power plants with other constraints than a personal website. In the former case you should focus on maintainability and ease of understanding and correctness - while in the second case the primary goal is likely to get it done as fast as possible to your personal liking.
I think operating systems are kind of similar. You can't always throw everything in VMs or containers that can malfunction. Sometimes it need to work. Surprises are bad.
Due to the changes surprises happen with systemd - that's the unavoidable problem.
> Nope, I'm a developer.
That's a different perspective and I'm sure that you experience systemd as a godsend for a lot of stuff that eases your life. Just different priorities. On the desktop I'm also happy to have some systemd based system that does the magic for me but with servers a lot of people have different expectations.
>Upstream as in it's included in the distribution but not primarily developed there.
Your claim was that most of the BSD's was from a shared upstream, with a few patches, and then listed things like OpenZFS and DTrace as examples, which again to my knowledge is only supported on FreeBSD of the BSD's... ?
>make from NetBSD, a driver from OpenBSD.
And lots of drivers from Linux as well, heck given that all but FreeBSD default to using GCC, I'd guess they (the different BSD flavors) have more code (as in lines) in common with a typical Linux distro than with eachother.
>IMHO defaults matter a lot. Sure, I can also turn it off with a small edit but then I need to remember the machines where it's on or off and I'm often don't have root.
But again it's the distros who choose the actual defaults you as a user will have, your distro is your actual upstream, not the systemd project.
>defaults related to the distro release...
Which is the same with differences between the BSD's, or different OS'es in general, which is what a distro is, a set of components combined in to an operating system.
>How is this a nonsense statement?
Because there is no objective definition on what constitutes as 'good reasoning' in this context, it's all subjective, depending on your needs/preferences.
>and I'm sure that you experience systemd as a godsend for a lot of stuff that eases your life.
Actually the impact for me has been minimal, slightly faster boot, slightly faster shutdown, and easier log examination.
> But again it's the distros who choose the actual defaults you as a user will have, your distro is your actual upstream, not the systemd project.
This is a dichotomy that does not exist in practice. It's the same people "upstream" as "downstream". In the cases of Debian, Ubuntu, and Arch, for examples, the distribution's listed maintainers are also systemd developers.
Not that one should take this as singular to systemd. The idea that there's some form of Chinese wall between a package's own developers and its maintainers at the various distributions is not reality in a number of places. Take mediawiki, for example. The person seeking to package it up and be its maintainer for Debian in 2016 is a Wikimedia Foundation software engineer.
>This is a dichotomy that does not exist in practice. It's the same people "upstream" as "downstream".
I believe that's nonsense. Out of all the software being packaged in all the distros out there, I would say only a very small amount is actually being packaged by people who are also upstream developers, there are LOTS of distros and LOTS and LOTS of packages out there.
>In the cases of Debian, Ubuntu, and Arch, for examples, the distribution's listed maintainers are also systemd developers.
systemd is a quite large project, some 250+ different committers, and from what I've read, neither Debian, Ubuntu or Arch will use the new default of shutting down user processes upon logout, despite them having upstream systemd developers responsible for the distro packaging.
> This is a dichotomy that does not exist in practice. It's the same people "upstream" as "downstream". In the cases of Debian, Ubuntu, and Arch, for examples, the distribution's listed maintainers are also systemd developers.
> I believe that's nonsense.
You can believe that if you like, but yours isn't a belief in any way founded in fact. Tomasz Torcz's 2014 lists of the top systemd developers includes the Debian, Ubuntu, and Arch maintainers.
Is it, that's not the impression I've gotten of the BSD's development, where is this shared upstream located ?
>Source lying in the same git repository is not tight coupling.
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.
>No one tells you what to do and most userland is pluggable
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.
>arbitrary new limits or changing default behavior or rewriting old tools in a manner that is disliked by some.
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.
>A lot of experienced devs and sysadmins also voiced conceptional and design complaints but I'm not able to judge that really. Some of it looks very reasonable.
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.
>TL;DR systemd is not just init - it changes Linux and causes fallout - FreeBSD was always popular and it's getting attractive for servers due to these changes.
Again, I don't agree with this conclusion, I don't think systemd is driving Linux users towards FreeBSD, to Gentoo perhaps or any other Linux distro which provides the flexibility and support of components which systemd and FreeBSD does not.