>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.
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.
>You're not an sysadmin or are you?
Nope, I'm a developer.