# Linus Torvalds Doesn't Recommend Using ZFS On Linux



## malaizhichun (Jan 11, 2020)

Linux kernel creator Linus Torvalds doesn't recommend using ZFS On Linux at least until Oracle were to re-license the code to make it friendly for mainline inclusion. But even then he doesn't seem turned on by the ZFS features or general performance.

Derailed from the recent mailing list discussion over Torvalds' thoughts on the Linux kernel scheduler, he responded to a post of a user complaining about the Linux kernel recently breaking the out-of-tree ZFS module.

Of course, Linus Torvalds has little control over the behavior of out-of-tree modules and it's always been his position to not maintain a stable driver API/ABI and they won't bend over backwards for closed-source/out-of-tree code. Out-of-tree modules are basically treated like they don't exist.

Linus wrote of ZFS on Linux:


> Note that "we don't break users" is literally about user-space applications, and about the kernel I maintain.
> 
> If somebody adds a kernel module like ZFS, they are on their own. I can't maintain it, and I can not be bound by other peoples kernel changes.
> 
> ...


----------



## Crivens (Jan 11, 2020)

Tho things:

No multi posts.
What is your point?


----------



## msplsh (Jan 11, 2020)

ZFS with GPL problems are not our problems.

Also, ZFS isn't as focused so much on performance as much as not losing your data, so in that regard, I'm not sure his opinion matters.

As for maintenance, there seems to be no shortage of people wanting to twiddle with it, just maybe too many forks.


----------



## vermaden (Jan 11, 2020)

Linus does not recommends ZFS.

I do not recommend listening to anything that Linus does or says nowadays.

He did not even recognized the difference between Oracle ZFS and OpenZFS ...


----------



## sidetone (Jan 11, 2020)

This conversation was on Reddit.

vermaden


----------



## mark_j (Jan 12, 2020)

Linus is a kernel developer, he's not a zfs developer; therefore he talks through his posterior and his opinion doesn't matter.
Regardless, my reading of it is he hates the licensing so he hates the software, which is hypocritical given the binary blobs scattered in his kernel. He's a supporter of GPL so he's the problem not zfs.
GPL is evil.


----------



## sidetone (Jan 12, 2020)

As for user end applications GPL is great. For dependencies, and libraries meant for multiple apllications to use, it's terrible. I'm not sure if the license is the cause for bloat, but the tw go together, and maybe encourage it. Certainly, it is misused. When they change their license to incorporate a freer license, it's a terrible showing of that culture, so that reason behind a GPL is really bad.

As far as I see, a story about Linus and Bill Gates makes me think he's short sighted. Bill gates attempted to rip him off once, and Linus didn't go for it. So, Gates immediately tried again, and how did he not figure out, if he tried to rip him off once, the next attempt would be to rip him of and not be gratuitous. First, Gates offered him maybe 10%, which would have been a ripoff. Then Gates offered him 90%. Linus would get a percentage of zero. Even if one couldn't see what the scam would be, how could you not know if he tried once, he'll try again.

So for his critiques on anything, you would have to consider he can't think ahead.


----------



## kpedersen (Jan 12, 2020)

I believe the ZFS codebase is pretty massive. Potentially one day if people get bored of it, it will be quite a large maintenance task.

Also, if Linux really is striving for GPL; having a perfectly good ZFS in the tree will potentially discourage developers to start a new GPL based one from scratch.


----------



## rigoletto@ (Jan 12, 2020)

kpedersen said:


> having a perfectly good ZFS in the tree will potentially discourage developers to start a new GPL based one from scratch.



This is Linux, there is a new one started from scratch every week and then abandoned before they finish it --- like BTRFS.


----------



## ralphbsz (Jan 12, 2020)

rigoletto@ said:


> This is Linux, there is a new one started from scratch every week and then abandoned before they finish it --- like BTRFS.


Exactly. And while BTRFS (I mean the one that eventually became the default on SUSE) was striving to copy ZFS's features, it never got most of them to work. And then it turned into a machine for creating data loss.

Oh, and you forgot to mention BTRFS (there are two with that name!) and BETRFS. Everyone who thinks they can implement a file systems starts doing so. And they all use Linux as the development platform. Now, it would be unfair to claim that this is the "fault of Linux", or that there is an evil Linux cabal trying to destroy the universe by creating bad file systems. Don't ascribe to malice what can be explained by incompetence! It's just random people who want to play with file systems, they happen to use Linux, they ship it as freely available software, and suddenly Linux has a lot more file systems.

In the meantime, we have the very good ext<n> series of file systems (not feature reach, no built-in data protection, but very well engineered, and reliable), and we have good of XFS (written by professional engineers at SGI, instead of drunk college kids), and we have ZFS. All very good file systems, although ZFS does stand out in data protection.

And since Linus has never been a working software engineer, and even less the leader of a software engineering organization, nor an expert in storage and file systems, his judgement calls on these topics are simply meaningless. And the people in the Linux ecosystem who make deployment decisions know that, and will ignore his rant. While in the meantime every paranoid and sensationalist drunk kid in the blogosphere will be claiming that the sky is falling, as is happening here on this forum right now.


----------



## mark_j (Jan 12, 2020)

rigoletto@ said:


> This is Linux, there is a new one started from scratch every week and then abandoned before they finish it --- like BTRFS.


I think this is so true.
Over the years of observing (and sometime using) Linux, I have come to these conclusions about the Linux ecosystem:
1) A stable software subsystem (for example, init) is seen as dangerously unmaintained because no bugs have been submitted for it in over a year and is therefore in need of immediate replacement.
2) "Not Invented Here" syndrome.
3) If it isn't GPLvN, then they need to make it GPLvN or otherwise they will denigrate it as useless and not Linux compatible.
4) Linux is an incoherent mess with far too many developers wanting to add their own to it. It's bloated and slow (and even Torvalds thinks this!)

Don't get me wrong, I think it has it use cases, but overall I would recommend Windows over Linux.


----------



## mark_j (Jan 12, 2020)

kpedersen said:


> I believe the ZFS codebase is pretty massive. Potentially one day if people get bored of it, it will be quite a large maintenance task.
> 
> Also, if Linux really is striving for GPL; having a perfectly good ZFS in the tree will potentially discourage developers to start a new GPL based one from scratch.




And it will only get more massive because Linux developers now have control of it. Feature creep and useless additions will become the norm; it's the Linux way. They hate stability. You watch.

The nail in the coffin will be when they integrate systemd into it... LOL


----------



## rigoletto@ (Jan 12, 2020)

mark_j 

GPLtards are parasites, if they can't suck it is useless for them... There are people using GPL for racional purposes, I saw some academic works that make sense to be GPL but most are just the automatic parasitic behavior.

ralphbsz 

Let me rephrase it t "Linux Ecosystem".


----------



## msplsh (Jan 12, 2020)

Init has limitations, so people want to solve them.  I wouldn't blame them for wanting something better... unfortunately "better" seems to be in the eyes of whatever RedHat decides, because he who writes the code, writes the rules.


----------



## sidetone (Jan 12, 2020)

The GPL3 seems parasitic as how it seemed to be based to take advantage of a newer BSD license. But the BSD license allows it, and there's no clear way to keep it for some free purposes and not for others. As long as it promotes good code, and isn't blocked by copyright trolls or an organization that tries to retroactively claim that code.

As for the entire movement, I can't say they're bad, because applications like Audacity, Ardour and Libreoffice which are for unselfish purposes have a GPL license. I've used those programs for what they're meant for.

I wonder if much of the bloat in GPL has to do with the license saying you must give back code, then everyone gives up code, which is a pile on because they feel compelled to do it. But I would say, it's from multiple organizations who want to combo license software to GPL, then they don't bother fixing major problems, because they don't want to give up improvements to a competitor who uses that same licensed program. I also suspect that RedHat and Gnome want things to be complicated on purpose.

There are cases where for-profit organizations using GPL works well and is unselfish, like Asterisk for instance. In cases where an application has too many uses, then GPL doesn't work well from for profits. GPL and similar licensing also works well for hobbyist applications or for those using applications largely created by an organization that wasn't code just skimmed off of another application with a less restrictive license.

GPL licensed code for widely available hardware not created by that organization? Now that's bad.


----------



## Remington (Jan 12, 2020)

Seems that many BSD users are against ZoL being included into future FreeBSD.  I also agree that FreeBSD shouldn't include ZoL for the main reason.. Linux communities have proven to be unreliable especially with their own history with BTRFS.  They'll will make ZoL much worse and unreliable.  FreeBSD ZFS has proven to be very solid and I've been running several servers with ZFS for over 5 years with no data loss.  BTRFS can't even do it.  I think FreeBSD should maintain their own ZFS apart from ZoL because one day ZoL will be a catastrophic failure waiting to happen.


----------



## vermaden (Jan 12, 2020)

ralphbsz said:


> Exactly. And while BTRFS (I mean the one that eventually became the default on SUSE) was striving to copy ZFS's features, it never got most of them to work. And then it turned into a machine for creating data loss.
> 
> Oh, and you forgot to mention BTRFS (there are two with that name!) and BETRFS. Everyone who thinks they can implement a file systems starts doing so. And they all use Linux as the development platform. Now, it would be unfair to claim that this is the "fault of Linux", or that there is an evil Linux cabal trying to destroy the universe by creating bad file systems. Don't ascribe to malice what can be explained by incompetence! It's just random people who want to play with file systems, they happen to use Linux, they ship it as freely available software, and suddenly Linux has a lot more file systems.
> 
> ...



EXT3 was very limited (even in its times) with 2TB file limit.

EXT4 almost killed KDE project because they (KDE) lost almost all of their repositories because of bugs in EXT4 filesystem:





						KDE Almost Lost All Of Their Git Repositories - Phoronix
					






					www.phoronix.com
				




XFS with metadata checksums is least shit in Linux native filesystems world, but XFS still does not provide data consistency like ZFS does.

BTRFS is currently ok in RAID0/RAID1 mode.

There is also project STRATIS in Red Hat which takes XFS over LVM to 'imitate' ZFS (so pathetic :ASD) and they plan to achieve checksums for data somewhere in the future - like in next 3-5 years of STRATIS development.


----------



## drhowarddrfine (Jan 13, 2020)

sidetone said:


> As for the entire movement, I can't say they're bad, because applications like Audacity, Ardour and Libreoffice which are for unselfish purposes have a GPL license.


I don't think the license had anything to do with it and those programs would be the same with a different one.


----------



## Datapanic (Jan 13, 2020)

I don't care what Linus Torvalds thinks.


----------



## mark_j (Jan 13, 2020)

msplsh said:


> Init has limitations, so people want to solve them.  I wouldn't blame them for wanting something better... unfortunately "better" seems to be in the eyes of whatever RedHat decides, because he who writes the code, writes the rules.


Actually, init does not have limitations. That's scope creep. Init starts the processes and then reaps the dead processes. Period.


----------



## mark_j (Jan 13, 2020)

sidetone said:


> The GPL3 seems parasitic as how it seemed to be based to take advantage of a newer BSD license. But the BSD license allows it, and there's no clear way to keep it for some free purposes and not for others. As long as it promotes good code, and isn't blocked by copyright trolls or an organization that tries to retroactively claim that code.



You could go back to the original BSD with the 'advertising' clause. We know that's not GPL compatible.


----------



## mark_j (Jan 13, 2020)

Remington said:


> Seems that many BSD users are against ZoL being included into future FreeBSD.  I also agree that FreeBSD shouldn't include ZoL for the main reason.. Linux communities have proven to be unreliable especially with their own history with BTRFS.  They'll will make ZoL much worse and unreliable.  FreeBSD ZFS has proven to be very solid and I've been running several servers with ZFS for over 5 years with no data loss.  BTRFS can't even do it.  I think FreeBSD should maintain their own ZFS apart from ZoL because one day ZoL will be a catastrophic failure waiting to happen.


I totally agree.
Scope creep is part of the Linux ethos, it seems. It will soon become so bloated and so cumbersome that it will be down to a niche few developers looking after it.  So if Lawrence Livermore National Laboratory suddenly loses interest after years of bloat creation, you're screwed.

I don't know the specifics, but I hope the development of ZFS is done so that FreeBSD (or NetBSD for that matter) can pull in what they want and still have a functioning ZFS.


----------



## CraigHB (Jan 13, 2020)

mark_j said:


> overall I would recommend Windows over Linux.



I'm afraid I feel the same way.  Some years ago I liked Linux hugely better, but it's lost all that ground.  Of course FreeBSD leaves both of them in the dust.


mark_j said:


> Actually, init does not have limitations



From my limited understanding the big complaint with `init` is that it can't load processes in parallel.  Seems to me like a small justification for replacing it with something largely more complicated, more monolithic, and more prone to issues (aside from its poorly written code).  So what's the big advantage, some milliseconds saved at boot?


----------



## kpedersen (Jan 13, 2020)

Remington said:


> I think FreeBSD should maintain their own ZFS apart from ZoL because one day ZoL will be a catastrophic failure waiting to happen.



I agree with this, even if ZoL doesn't screw up. Mostly because FreeBSD will become a second class citizen again. It will always be the one catching up.
ZoL will probably also do something weird like tie ZFS to systemd/Linux cgroups making it a big faff to maintain a portable patchkit.

I personally would prefer an "out-of-date" but rock solid "native" implementation of ZFS.

But ultimately it is up to the FreeBSD developers. ZFS is massive so I can understand why they want to pass on some of the maintenance burden to an external project.


----------



## mark_j (Jan 13, 2020)

CraigHB said:


> From my limited understanding the big complaint with `init` is that it can't load processes in parallel.  Seems to me like a small justification for replacing it with something largely more complicated, more monolithic, and more prone to issues (aside from its poorly written code).  So what's the big advantage, some milliseconds saved at boot?



Well I'm also not a systemd aficionado but my understanding is also that it is/was their main motivation. Of course this is based on their main demographic being those who constantly reboot, apparently. For servers, who cares how long they take to boot because if the system is stable and reliable that should happen rarely if ever.

I too cannot understand complicating a simple process for the sake of seconds saved in booting. Just use an SSD or stop loading unnecessary daemons at the start. When you look at some of the Linux distributions, no wonder they want faster and parallel boots, they load so many useless programs it's mind blowing.


----------



## Crivens (Jan 13, 2020)

I heard that one driving force behind systemd were embedded users. Your car audio f.e. boots up when your key comes into range so it can be "instantly on" when you open the door 3 seconds later. There, every millisecond counts.


----------



## kpedersen (Jan 13, 2020)

Crivens said:


> I heard that one driving force behind systemd were embedded users



Its strange because I would imagine very few services would need to be started up in this use-case so perhaps no-init system (or a trivial script) would be preferred instead of even systemd.

If I had to guess. I always had the feeling that systemd made integration with GUIs much easier than freeform scripts (which is becoming very important for the modern Linux user). I.e it is much easier to change a Windows 3.1 style .ini file than to munge a shell script.
Whilst the "programmer" in me actually prefers systemd, the "UNIX aficionado" in me is deadly against it.


----------



## Crivens (Jan 13, 2020)

kpedersen
You lucky one, you can have a god punch up when drunk all by yourself


----------



## msplsh (Jan 13, 2020)

Being against improving init to gain parallelization is just as dogmatic as being against ZFS in principle because it's not the license you want.

Please don't confuse "improving init" to be "systemd is improved init"


----------



## CraigHB (Jan 13, 2020)

kpedersen said:


> ZFS is massive so I can understand why they want to pass on some of the maintenance burden to an external project



Can't blame them for that I suppose, work is work.  Though it could end up being more work to keep it going with FreeBSD if the GNUtards decide to so some Linux-y things with it, pretty likely I'd say. Could be ugly.

I think the climate for FreeBSD is pro Linux right now, but I'd rather they not get too involved with it or influenced by it.  Though I do need that compatibility layer. There is a specialty Linux app I use that will never be available in ports.


Crivens said:


> I heard that one driving force behind systemd were embedded users.



I have an AMLogic TV box that runs CoreELEC (Linux).  I have to admit it cold boots impressively fast.  Though I don't know how much I can attribute that to the skill of the CoreELEC developers (which is impressive) or to Linux and systemd itself.


----------



## Remington (Jan 13, 2020)

kpedersen said:


> I agree with this, even if ZoL doesn't screw up. Mostly because FreeBSD will become a second class citizen again. It will always be the one catching up.
> ZoL will probably also do something weird like tie ZFS to systemd/Linux cgroups making it a big faff to maintain a portable patchkit.
> 
> I personally would prefer an "out-of-date" but rock solid "native" implementation of ZFS.
> ...



It's not about being 2nd class.  FreeBSD have reputation as a conservative OS with ultra stability, reliability and security in mind.... unlike Linux.

I think it's more sensible for FreeBSD ZFS developers to examine ZoL codes before pulling the codes into FreeBSD ZFS.  I'm more interested in ZFS encryption but I wouldn't want them to pull in everything blindly because one day ZoL will really screw up and tarnish Linux reputation... not FreeBSD.  I know as a developer, tweaking one thing can break 2 or 3 other things and the list goes on.  Linux developers really likes to tweak things more than necessary.


----------



## SirDice (Jan 13, 2020)

Linus Torvalds says “Don’t use ZFS”—but doesn’t seem to understand it
					

Linus should avoid authoritative statements about projects he's unfamiliar with.




					arstechnica.com


----------



## cynwulf (Jan 13, 2020)

vermaden said:


> He did not even recognized the difference between Oracle ZFS and OpenZFS ...


I'm not 100% certain, but I believe he was referring to the licensing.  OpenZFS is released under the CDDL, a GPL incompatible licence, as with OpenSolaris, so it can't be combined with the GPL v2 Linux kernel.  I believe that only Oracle could change the licence?


----------



## vermaden (Jan 13, 2020)

cynwulf said:


> OpenZFS is released under the CDDL, a GPL incompatible licence, as with OpenSolaris, so it can't be combined with the GPL v2 Linux kernel.  I believe that only Oracle could change the licence?


Bad reasoning ... CDDL is perfectly ok with GPL, its the GPL that is not compatible with CDDL.


----------



## Eric A. Borisch (Jan 13, 2020)

1) Don’t conflate Linux developers and ZFS on Linux developers.

2) the OpenZFS plan going forward is to have FreeBSD, MacOS, Linux, and any other supported platforms to all be hosted in the same OpenZFS repository (renamed from ZFS on Linux.) This will include test suites running against FreeBSD such that any breakage is detected early (when it is comparatively much easier to address), and will make it much easier for different platforms to have the same (or at least much more similar) feature sets.

I’ve seen zero reason to be concerned with ZoL in general (as a long time user on both platforms, and OpenSolaris before that) ... yes, there have been some small bumps, typically due to variances across different Linux distributions handling of kernel upgrades, but those are exactly the portions of the code base that FreeBSD’s ZoL won’t be utilizing.


----------



## Crivens (Jan 13, 2020)

I'm somehow caught in a quantum state of believing and not believing they had no test suite on Linux for this. But well, gcc and cygnus comes to mind again.


----------



## Eric A. Borisch (Jan 13, 2020)

Crivens said:


> I'm somehow caught in a quantum state of believing and not believing they had no test suite on Linux for this. But well, gcc and cygnus comes to mind again.



I did not say there was "no test suite for Linux", I'm saying they will be adding a FreeBSD buildbot to perform automated checks. Or were you referring to the kernel upgrade issues? That's a thorny one to try to have perfect testing for, since so much depends on the history of the system and when the operator chooses to apply updates. But that's not a FreeBSD discussion, so I will leave it at that.

The whole presentation is worth reviewing or watching. Slide 14 has the bulk of the information:

Lots of work to reorganize ZoL code to abstract out the Linux-specific bits
FreeBSD uses a different compiler (llvm, not gcc)
Trying to do things “the right way”, fix linuxism’s that have crept in
E.g. renaming functions/types that conflict with OS-provided ones rather than abusing the preprocessor

WIP code is functional and runs test suite on FreeBSD
Work being lead by iXsystems engineers
60+ PR’s already landed, ~10 currently open
~50,000 lines of code yet to land (mostly FreeBSD-specific)

Lots of upstreaming and code review still needed
FreeBSD buildbot integration in progress


----------



## ralphbsz (Jan 13, 2020)

CraigHB said:


> From my limited understanding the big complaint with `init` is that it can't load processes in parallel.  Seems to me like a small justification for replacing it with something largely more complicated, more monolithic, and more prone to issues (aside from its poorly written code).  So what's the big advantage, some milliseconds saved at boot?


This complaint about the traditional init is old, and correct. There have been research/hacking papers presented at conferences as early as the late 90s or early 2000s that demonstrated that a parallel init can be much faster. Often the saving is 3x or something like that. Although sometimes the difference sometimes ends up being minor, because with spinning disks, system bootup may be disk limited, with the disk nearly continuously busy with random seeks. There was an interesting study (I think a PhD thesis) about how to improve that by grouping files on disk by access order during boot, which also demonstrated great improvement. And in those days, it often took 5 minutes for a system to boot (in particular a server with many services), so a speedup by a factor of 3 is VERY significant.

Today with SSDs (very little seek time), the landscape has changed: During booting, a system is no longer purely random IO limited. Yet, many init tasks today end up being network limited, and those latencies still exist. On the other hand, machines today hav multiple cores, so having parallel tasks during init is both less important and more important than it used to be.

So the important thing is: faster init is not "milliseconds" or "seconds", it can amount to several minutes, and it can be the long pole in the tent for recovery time. This stuff matters in many environments.

There are way more use cases for fast booting than just embedded computing. One particularly near to my heart is kernel development: for lack of good debugging techniques, one often ends up crashing the kernel, collecting a dump, rebooting, analyzing the dump, and trying again. In the old days (say ~98), that was often a 5-10 minute cycle. In one particular example, a colleague and me got that down to 27 seconds without hardware changes, and the difference in productivity is very significant. Another important reason for fast boot times is asynchronous servers: If a web page takes 30 seconds to load, many users (in particular internal users) will be mildly upset, but not walk away; if a web page takes 10 minutes to load, users will change their workflow, and productivity is disrupted. Having really fast boot times often makes it unnecessary to have redundant servers or reliable hardware (for example for planned maintenance), if instead one can crash the server and it comes back up really fast. On particular example of great cost savings: handling power outages. It used to be that serious computers had both UPSes (to handle short power outages) and diesel generators, which kick in after a minute of outage. Today, with fast boot times and better generators, we can often get rid of the UPSes: if the power fails, the server just crashes, within 10 seconds the diesel is up, and another 30 seconds later the server is back online. And the cost saving of that is large, since UPSes (with their short-lived batteries and regular battery maintenance) are expensive. Obviously, this requires looking at the whole system; having a UEFI BIOS that takes 3 minutes to initialize the motherboard, or needing to run fsck for 5 minutes does not work in such an environment.

Disclaimer: I have no idea whether fast boot times are actually what drove Lennart to work on systemd; I've never asked him for his motivation.


----------



## unitrunker (Jan 13, 2020)

I find a lot of init system comparisons are flat wrong. So many people think all BSDs use the system V init instead of rc. 1998 was a long time ago. This is a worthwhile topic for another thread.


----------



## mark_j (Jan 14, 2020)

msplsh said:


> Being against improving init to gain parallelization is just as dogmatic as being against ZFS in principle because it's not the license you want.
> 
> Please don't confuse "improving init" to be "systemd is improved init"


How is parallelization improving init? It brings with it its own set of issues and complications. Speed is not everything, but stability and being able to boot consistently is. 
You might have wanted to parallel run init services back in the 90s or early 2000s but now, with SSDs and NVMe SDs, who cares.


----------



## mark_j (Jan 14, 2020)

SirDice said:


> Linus Torvalds says “Don’t use ZFS”—but doesn’t seem to understand it
> 
> 
> Linus should avoid authoritative statements about projects he's unfamiliar with.
> ...


Thank you for the link. I think this is a very informative article.

It shows the deep-seated spite ingrained in a lot of (if not most) Linux kernel developers for any license that isn't GPL. It shows why FreeBSD being too chummy with Linux is like playing with a hand-grenade and a rusted pin.
I guess this is all fostered by Torvalds who has always been a "my way or the highway" authoritarian "leader".


----------



## sidetone (Jan 14, 2020)

There are arguments that Linux will mess things up, and how Linus' opinions are dubious, counter to that Linus rejects ZFS. He's kind of doing FreeBSD a favor.
===
One problem with any init is when a program like ntpd stalls because it can't find an internet connection.


----------



## CraigHB (Jan 14, 2020)

That article was pretty interesting.  There's a lot more to OpenZFS and operation with various systems than I thought.  Though why the change of name to ZFS on Linux, why not just stick with OpenZFS?

Having a late model laptop that runs 12 logical cores with NVMe drives I can say it does everything ridiculously fast even though it runs Windows.  So I don't know, is the old sequential loading init system going to be a problem or even a consideration for FreeBSD down the line?

My last FreeBSD system seemed to boot pretty quick and that was an old system I retired recently.  The new system I'm putting together for FreeBSD will have all the latest stuff like 16 logical cores and NVMe drives.  Will be interesting to see how that does in terms of boot speeds.

I have a lot of trepidation in seeing any changes to the init system since I'm used to and comfortable with what FreeBSD has been using forever.  If they do go to a parallel loading init system down the road I just hope they do it right.  Ideally it should be transparent to me in terms of configuration and administration, you know principle of least astonishment and all.


----------



## Vadim_Mkk (Jan 14, 2020)

The dog barks but the caravan goes © proverb
On the one hand  seems that  ZFS  interferes with some plans   RedHat-IBM own filesystems , because Linus earn their money from RedHat. What says Linus Torvalds - that says RedHat-IBM.
On the other hand Canonical has own plans for ZFS - ZFS native root includes to Ubuntu 19.10 and how I understand ZFS native root will be include to  Ubuntu 20.04 LTS.
I think that life will take its toll and  ZFS in the near future will be aviability natively root install in different Linux distro.
In my opinion  Linus Torvalds -  a bloated dummy, bloated by RedHat and crazy Richard Stallman and hysteria 1990s with FreeSoftware, which stretched out  the lucky ticket during a lawsuit against BSD  in the 1990s.


----------



## ralphbsz (Jan 14, 2020)

CraigHB said:


> Having a late model laptop that runs 12 logical cores with NVMe drives I can say it does everything ridiculously fast even though it runs Windows.  So I don't know, is the old sequential loading init system going to be a problem or even a consideration for FreeBSD down the line?


Sorry to be blunt, but your experience on a laptop is irrelevant. A very large fraction of all computers in the world are either embedded or servers. Actual human interface machines are a small minority. Is faster booting relevant? Yes for embedded systems, where you want to come up fast (for example because you are acquiring data, or a human is waiting to press buttons on his dishwasher), and you don't have the luxury of running redundant servers (so while one server boots, the other is still serving). It is also highly relevant for servers, because (a) it greatly improves the effective uptime of servers, (b) it may allow one to get rid of the need for redundant backup server of battery-powered UPSes.



Vadim_Mkk said:


> On the one hand  seems that  ZFS  interferes with some plans   RedHat-IBM own filesystems , because Linus earn their money from RedHat. What says Linus Torvalds - that says RedHat-IBM.


I would not assume that Linus says things because his employer wants him to do that. He's always been quite independent of where his paycheck comes from. Whic doesn't mean that he's always right, nor that he is easy to interact with.



> In my opinion  Linus Torvalds -  a bloated dummy, ...


I strongly disagree. He's smart, and knowledgable about many things. But that doesn't imply that his public pronouncements are always correct, because he can be quite misguided. And the way he interacts with people in the Linux and kernel world doesn't always reflect his private style.


----------



## xtremae (Jan 14, 2020)

mark_j said:


> How is parallelization improving init? [..] who cares.



Everything operating at scale, including but not being limited to virtualization, containers, (micro)services, infrastructure and paid compute. Shaving off a full second on the init translates to getting back years of wasted compute on a daily basis. Servers these days are virtual --like apps-- and paying customers want to be able to (re)configure and start them quickly.

That said, if your only concern is your laptop I don't think parallel service startup is all that important.


----------



## shkhln (Jan 14, 2020)

Vadim_Mkk said:


> because Linus earn their money from RedHat



You might want to do some fact-checking.


----------



## ralphbsz (Jan 14, 2020)

shkhln said:


> You might want to do some fact-checking.


The financial report of Linus' employer can be found online. It shows how much he makes, and where the money comes from. In the interest of privacy, I won't post it here.


----------



## msplsh (Jan 14, 2020)

Linus is employed by the Linux Foundation.  RedHat is only one member among many.


----------



## mark_j (Jan 14, 2020)

xtremae said:


> Everything operating at scale, including but not being limited to virtualization, containers, (micro)services, infrastructure and paid compute. Shaving off a full second on the init translates to getting back years of wasted compute on a daily basis. Servers these days are virtual --like apps-- and paying customers want to be able to (re)configure and start them quickly.
> 
> That said, if your only concern is your laptop I don't think parallel service startup is all that important.



And so you have OSs rebooting every second of every day inside these VMs? Because that's what it would take to get years back from a second saved rebooting. This seems like a spurious argument to me. Paying customers paying per second for a server is unheard of (at least by me).

Don't get me wrong, parallelization of an init has some merit, some times, BUT it has a big down side. It requires synchronization. If the market Linux chases needs this, then more power to them. My argument is, and always will be, that for the likes of FreeBSD they should avoid it at all costs.


----------



## ralphbsz (Jan 14, 2020)

mark_j said:


> And so you have OSs rebooting every second of every day inside these VMs? Because that's what it would take to get years back from a second saved rebooting.


The large cloud companies each have dozens or hundreds of million servers. A year has about 31 million seconds, so saving a second per boot amounts to saving roughly a whole server per year.



> Paying customers paying per second for a server is unheard of (at least by me).


I pay by the millisecond. At least bills claim to be accurate to the millisecond of CPU usage.



> Don't get me wrong, parallelization of an init has some merit, some times, BUT it has a big down side. It requires synchronization. If the market Linux chases needs this, then more power to them. My argument is, and always will be, that for the likes of FreeBSD they should avoid it at all costs.


Do you know what the market for FreeBSD is? What the people in charge of FreeBSD want it to be?
And: It is impossible to claim that "Linux" chases a particular market. There are lots of different things in the Linux ecosystem, which are after very different markets. RHEL (the commercial supported offering) is very different in market positioning from Fedora, and those two even come from the same company.

I understand your tradeoff: parallel init is (just like parallel make and multi-core software) inherently hard, harder than sequential. If a particular group of users doesn't need the benefit and can't handle the complexity, disabling it for them might make sense. It might also not make sense: Parallel init works perfectly, if the dependency graph is specified correctly; allowing users to be sloppy about it is something you can usually get away with in a sequential init, but it will occasionally bite you. From that viewpoint, using a parallel init is actually an exercise in system hygiene.


----------



## Eric A. Borisch (Jan 15, 2020)

Phishfry said:


> Yea but who reboots them? A server by definition should not need rebooting except for critical updates. 5 nines means only 5 seconds downtime a year.



99.999% (five nines) is five _minutes_ of downtime a year.


----------



## Phishfry (Jan 15, 2020)

I had to delete that silly comment. I am trying to stay out of the fray. I thought uptime was more important.


----------



## mark_j (Jan 15, 2020)

ralphbsz said:


> The large cloud companies each have dozens or hundreds of million servers. A year has about 31 million seconds, so saving a second per boot amounts to saving roughly a whole server per year.


Even if I accept 100s of millions, this saving for the sake of a massive change to an init service is ridiculously small it's inconsequential.
I don't know how often you reboot a server, but I try to avoid this at all costs. I cannot see AWS, for example, constantly rebooting servers. Why would they bother if they can reboot the VMs. How long the VMs take to reboot is moot because they merely swap you off to another. They do have spare ones.

I'm sorry, but I'm not seeing cost savings anywhere. I think it's a very long bow to draw. The cost/benefit of parallelization is not there.



ralphbsz said:


> Do you know what the market for FreeBSD is? What the people in charge of FreeBSD want it to be?
> And: It is impossible to claim that "Linux" chases a particular market. There are lots of different things in the Linux ecosystem, which are after very different markets. RHEL (the commercial supported offering) is very different in market positioning from Fedora, and those two even come from the same company.



The goal is stated in the handbook, the foundation ratifies this with a goal of supporting infrastructure that is server oriented, hence the Tier 1 selections and take up to Armv8. But why the question? Perhaps their goal would be clearer should they change their name to NetflixBSD?

It is clear the server market is what FreeBSD is chasing. They are not desktop and they're not embedded. They have minimal to poor support of laptops, so what else is left? By deductive reasoning and the stated goals of the foundation, it's pretty obvious where their attentions lie.

On that basis, parallelization and tampering with the init system is a bogus project with lots of risks and very little return.


----------



## CraigHB (Jan 15, 2020)

I'd be happy if they left the init system alone, no skin off my nose, but I'm just a desktop user.  Have to let the guys who do the heavy lifting with FreeBSD make those kind of decisions.  If a faster init system is something they're concerned with then I guess it could happen.  Haven't read much about that here and there are professional admins on this forum.

I can understand the need for a faster init system with embedded where purpose built appliances need to come up pretty quick.  FreeBSD is not really going there with ARM sitting at tier two and I don't believe that's going to change in the near future.  That makes it moot at this point.


----------



## teo (Jan 15, 2020)

Linus Torvalds has reasons to say clearly what ZFS is, the reasons are because he doesn't see the file system as such a relevant technology and has no real maintenance. Considering Oracle's litigious,  nature given the claim of the oracle interface ( Java ) I don't think it's a real license and performance gain either.


----------



## Vadim_Mkk (Jan 15, 2020)

xtremae said:


> That said, if your only concern is your laptop I don't think parallel service startup is all that important.











						Linus Torvalds Net Worth
					

Linus Torvalds Net Worth and Salary: Linus Torvalds is a Finnish software engineer who has a net worth of $50 million. Torvalds is probably best




					www.celebritynetworth.com
				











						Linus Torvalds: The King of Geeks (And Dad of 3)
					

The license plate on Linus Torvalds' Mercedes SLK convertible says it all. The frame running around the outside of the plate says "Mr. Linux. King of All Geeks," but the plate itself reads "Dad of 3." Linus Torvalds has reached middle age, and so has Linux. Nowadays, it's easy to take both of...




					www.wired.com
				











						Linus Torvalds Net Worth 2022: Wiki, Married, Family, Wedding, Salary, Siblings
					

Linus Benedict Torvalds was born on 28th December 1969, in Helsinki, Finland. Currently, he resides in USA. Torvalds became famous as an engineer of computer software who created the kernel of Linux. Later, the kernel was used for other operating systems. Currently, Linus works for The Linux...



					networthpost.org
				



How speak in Russia - He doesn't  eat up last horseradish without salt


----------



## rigoletto@ (Jan 15, 2020)

With 150M he is just arriving at the group of super rich.


----------



## brd@ (Jan 15, 2020)

CraigHB said:


> I can understand the need for a faster init system with embedded where purpose built appliances need to come up pretty quick.  FreeBSD is not really going there with ARM sitting at tier two and I don't believe that's going to change in the near future.  That makes it moot at this point.



Actually, we are working on getting ARM to Tier 1 for 13.


----------



## Hakaba (Jan 15, 2020)

My interest : Is ZFS still considered as an important feature in FreeBSD ?
(The answer is yes with the current informations)

The ideologic war in Opensource licence world is not my cup of tea.

But it is for some people, so if systemd is a very good evolution, why there is no «BSD licenced systemd like» initiative ?


----------



## msplsh (Jan 15, 2020)

Hakaba said:


> But it is for some people, so if systemd is a very good evolution, why there is no «BSD licenced systemd like» initiative ?



It's called OpenRC

Here's some more:





						Comparison of init systems - Gentoo Wiki
					






					wiki.gentoo.org


----------



## recluce (Jan 16, 2020)

ralphbsz said:


> Sorry to be blunt, but your experience on a laptop is irrelevant. A very large fraction of all computers in the world are either embedded or servers. Actual human interface machines are a small minority. Is faster booting relevant? Yes for embedded systems, where you want to come up fast (for example because you are acquiring data, or a human is waiting to press buttons on his dishwasher), and you don't have the luxury of running redundant servers (so while one server boots, the other is still serving). It is also highly relevant for servers, because (a) it greatly improves the effective uptime of servers, (b) it may allow one to get rid of the need for redundant backup server of battery-powered UPSes.



Fast boot can be achieved with much better tools than systemd, which is not that fast in booting anyway. OpenRC without parallelization is close, with (optional) parallelization it is faster. Probably because it doesn't have all the overhead and bloat that systemd has. A customized, purpose-built boot script likely does even better on an embedded device (known hardware specs).

On a server worth the name, boot time is totally irrelevant. No real server is running without a UPS and a generator, if it is really important, it must have both a fail-over or be clustered *and* have a DR site fail-over on top of that. Who cares about single server boot times in such a scenario? Nobody. Boot time on my servers is typically limited by the boot post of controllers and other I/O cards as well as the typically slow boot post of a server BIOS. The difference caused by init really is not important.

Effective uptime: A slow server under BSD might take a minute or two to come up. If that server is rebooted once every three months (which I feel is a reasonable average), this means a maximum of eight minutes a year - or a difference of 0.0016% in uptime. That is nothing. 

I guess you lose a lot more uptime due to systemd shenanigans.


----------



## Peter Eriksson (Jan 16, 2020)

recluce said:


> Effective uptime: A slow server under BSD might take a minute or two to come up. If that server is rebooted once every three months (which I feel is a reasonable average), this means a maximum of eight minutes a year - or a difference of 0.0016% in uptime. That is nothing.
> 
> I guess you lose a lot more uptime due to systemd shenanigans.



Try 1 hour boot times... When you have big FreeBSD servers with (ten)thousands (and snapshots on top of that) of ZFS filesystems boot time (and let's not talk about shutdown time for that matter) takes a long time.

We have modified our startup scripts so that we do some things in the background (we make sure root/important filesystems are mounted first, then the rest is done in the background -  and then some other things also have to be done in the background (that needs the rest of the filesystems to be mounted). Having to wait (up to - things have become better with the "zfs parallell mount" support in later FreeBSD versions) an hour for a server to fully boot before getting a login prompt is not so nice... But it's still a hack that really could use better "built in" parallell/dependency support.

The parallell-with-dependency handling startup (and auto-restarting of services) stuff is one of the biggest things I miss the most from our Solaris servers.


----------



## Vadim_Mkk (Jan 16, 2020)

I heard that boot


Peter Eriksson said:


> Try 1 hour boot times... When you have big FreeBSD servers with (ten)thousands (and snapshots on top of that) of ZFS filesystems boot time (and let's not talk about shutdown time for that matter) takes a long time.


How I heard systemd doesn't radicaly burst the boot time Linux server with thousands ZFS dataset and snapshot.


----------



## Crivens (Jan 16, 2020)

Peter Eriksson Dude, what is that thing for? That sounds massive, but I'd wager that boot times would be better with faster IO and that stuff like systemd will not really help.


----------



## msplsh (Jan 16, 2020)

The post literally describes how an init-hacked parallel boot and delayed mounting solves some their problem, so yes, system level support WOULD help.


----------



## recluce (Jan 16, 2020)

Peter Eriksson said:


> Try 1 hour boot times... When you have big FreeBSD servers with (ten)thousands (and snapshots on top of that) of ZFS filesystems boot time (and let's not talk about shutdown time for that matter) takes a long time.



With 1 hour boot times, I would lean towards the theory that your system design could be improved....


----------



## kpedersen (Jan 16, 2020)

recluce said:


> With 1 hour boot times, I would lean towards the theory that your system design could be improved....



Buy another machine and split the workload?
30 minutes boot time!


----------



## Phishfry (Jan 16, 2020)

My 24 drive array only takes 120 seconds. An hour does sound extreme.
Question is what exactly could you do with the 1 hour if you had parallel startup processes?
On my fileserver there is nothing I could do until the arrays come up.
So I fail to see the advantage of a storage server coming up without the storage..


----------



## mark_j (Jan 18, 2020)

Peter Eriksson said:


> Try 1 hour boot times... When you have big FreeBSD servers with (ten)thousands (and snapshots on top of that) of ZFS filesystems boot time (and let's not talk about shutdown time for that matter) takes a long time.
> 
> We have modified our startup scripts so that we do some things in the background (we make sure root/important filesystems are mounted first, then the rest is done in the background -  and then some other things also have to be done in the background (that needs the rest of the filesystems to be mounted). Having to wait (up to - things have become better with the "zfs parallell mount" support in later FreeBSD versions) an hour for a server to fully boot before getting a login prompt is not so nice... But it's still a hack that really could use better "built in" parallell/dependency support.
> 
> The parallell-with-dependency handling startup (and auto-restarting of services) stuff is one of the biggest things I miss the most from our Solaris servers.



Two points:
1. That's your design problem.
2. It's not an init problem.

Look at https://svnweb.freebsd.org/base?view=revision&revision=344569


----------



## Peter Eriksson (Jan 18, 2020)

kpedersen said:


> Buy another machine and split the workload?
> 30 minutes boot time!



It's already split over 10 servers... , and with the parallell mount support in zfs now the boot times are down to around 10 minutes (unless it was an unclean shutdown and the ZFS filesystems happen to have "unflushed" changes (forced reboot while destroying snapshots and/or lokts of files/directories that needs to be handled - something ZFS does synchronously at boot/mount time - so it might look like a server is "hung" for a very long time (have seen a case where it took like 10 hours).

The thing with ZFS is that it isn't the number of drives that is the problem - it's the number of filesystems (we have one filesystem per user, and so some 20k filesystems per server - and then hourly and daily snapshots)... But it's getting better 




Phishfry said:


> My 24 drive array only takes 120 seconds. An hour does sound extreme.
> Question is what exactly could you do with the 1 hour if you had parallel startup processes?
> On my fileserver there is nothing I could do until the arrays come up.
> So I fail to see the advantage of a storage server coming up without the storage..
> View attachment 7417



A couple of things: 

1. It's really nice to be able to login to the server (get a "login:" prompt, via console or SSH) so you can debug _why_ it's taking so long to start... (This was the first reason why we do the "zfs mount -a ; zfs share -a" command in the background - it was really frustrating to have to wait for everything to be mounted and started before being able to login (as root).

2. We start the Samba (SMB) server before all the filesystems are mounted so that the users that have their home directories mounted can access them as soon as they are there - no need to have to wait for all the users homes to be mounted before giving access.

3. Same as with NFS shares - export them as soon as they are available.... But the NFS and the Samba startup could be done in parallell (now Samba starts up pretty quickly, it's just the enumeration of our Window AD with some 120k users that takes some time there). And NFS sharing is much quicker nowadays too. 

But still it would be nice if one could specify dependency graphs and have some things start up in parallell (where it can).


----------



## Peter Eriksson (Jan 18, 2020)

Crivens said:


> Peter Eriksson Dude, what is that thing for? That sounds massive, but I'd wager that boot times would be better with faster IO and that stuff like systemd will not really help.



University file servers for users, groups and research & teaching stuff. Around 1000TB of data right now.

But yeah, Systemd (or some other "parallell" alternative) doesn't really help _that_ much in day-to-day work since the server normally aren't rebooted. It's just when the shit has hit the fan that it would be nice (we've "solved" it ourself on our servers by starting some services in the background via some hacks in the /etc/rc.d startup scripts). 
There are actually two things I "miss" from the Solaris days:

1. The parallell startup of services at boot time

2. That the system can "reheal" itself (automatically detects if a service dies and tries to restart it - and since it knows which services depends on the failed one - can automatically restart/refresh those too)

But to be clear: I don't like the bloatedness of systemd, would much prefer something more "clean"...


----------



## mark_j (Jan 18, 2020)

Peter Eriksson said:


> 2. That the system can "reheal" itself (automatically detects if a service dies and tries to restart it - and since it knows which services depends on the failed one - can automatically restart/refresh those too)
> 
> But to be clear: I don't like the bloatedness of systemd, would much prefer something more "clean"...



This can be accomplished with perp (/usr/ports/sysutils/perp/) or daemontools (/usr/ports/sysutils/daemontools/ ), if you need.


----------



## Crivens (Jan 19, 2020)

Peter Eriksson said:


> University file servers for users, groups and research & teaching stuff. Around 1000TB of data right now.
> 
> ...
> 
> But to be clear: I don't like the bloatedness of systemd, would much prefer something more "clean"...


Spoiled students... 
But you may have a look at 'minit' from fefe, it's said to do all that but also that looking at the code will make you suicidal.


----------



## aht0 (Jan 20, 2020)

sidetone said:


> There are arguments that Linux will mess things up, and how Linus' opinions are dubious, counter to that Linus rejects ZFS. He's kind of doing FreeBSD a favor.


Yeah, as long as the status of ZFS in Linux remains questionable (kernel devs hostile to it, out-of-tree _etc_), there is no danger of FreeBSD becoming 'second class citizen' in OpenZFS.


----------



## TW1920 (Jan 21, 2020)

Working primary for a hosting company I can say that the usual Linux FS are very limited in their stability. On own projects or earlier projects and some of friends mostly used ZFS - and with ZFS there were never any problem.

You want to create a bigger raid with SSD Cache on Linux? Or any other Cache for it? It's risky and make only problems, more than you can earn on performance.
Linux may have some benefits in some points, but finally if you want a very reliable system my experience is on FreeBSD much better! And if you use good and the right Hardware you should never have problems with ZFS - it's just working. And I think I'm not alone with this opinion.
In my opinion it's the philosophy behind the development. (Lot of you already wrote about it in this thread^^)

That's the reason I'm moving away from Linux to FreeBSD based. And lot of friends have done this before.


----------



## Vadim_Mkk (Jan 21, 2020)

The monstrous, the senseless and merciless  GRUB for Zfs on Linix...
When install GRUB involuntarily  to grudge   that the  history didn’t go the other route:
"If 386BSD had been available when I started on Linux, Linux would probably never had happened"  ©  Linus Torvalds 1993


----------



## weberjn (Jan 26, 2020)

teo said:


> Linus Torvalds has reasons to say clearly what ZFS is, the reasons are because he doesn't see the file system as such a relevant technology and has no real maintenance. Considering Oracle's litigious,  nature given the claim of the oracle interface ( Java ) I don't think it's a real license and performance gain either.



Assuming Linus Torvalds' misgivings concerning Oracle are valid, could this be a problem for FreeBSD using ZFS, too?
Why would Linux have a problem and not FreeBSD?


----------



## mark_j (Jan 26, 2020)

weberjn said:


> Assuming Linus Torvalds' misgivings concerning Oracle are valid, could this be a problem for FreeBSD using ZFS, too?
> Why would Linux have a problem and not FreeBSD?


Because Torvalds has no idea what he's talking about?

His license concerns are about including something not compatible with his GPLv-whatever Linux kernel. That's his problem, not any of the BSDs. He uses that stupid licensing system GPL, so let him deal with it. He also seems to be totally confused about openZFS and ZFS from Oracle. He's the owner of Linux, he's not a file system developer but unfortunately any crap spewed from his mouth is treated as gospel by the Linux believers and this is where all the confusion seems to be. He could solve the problem, immediately, by re-licensing the kernel code to BSD-style.  

Anyway, Linux has about 100 different file systems to choose from (and growing), so why should he be worried about ZFS! (Ok the number is probably a bit of an exaggeration...)

ZFS, which is now under control of Linux-style developers will no doubt head down the path of bloat and sloth as they steadily add more and more "features" to it, just like they do to windowing compositors, kernels, init systems, you name it.


----------



## mark_j (Jan 26, 2020)

Hakaba said:


> My interest : Is ZFS still considered as an important feature in FreeBSD ?
> (The answer is yes with the current informations)
> 
> The ideologic war in Opensource licence world is not my cup of tea.
> ...


Not for lack of trying I think. 
I watched Benno Rice (previous FreeBSD core member) pour scorn on FreeBSD in his talk (available on youtube) because they (whoever 'they' are) would not countenance FreeBSD adopting something like systemd. He seems to love the concept. 

Hopefully his pleas for systemd on FreeBSD have fallen on deaf ears. Apple has launchd, which seems to be the basis for Poettering's systemd and I don't see a lightning fast or particularly stable OS because of it!


----------



## weberjn (Jan 26, 2020)

weberjn said:


> Assuming Linus Torvalds' misgivings concerning Oracle are valid, could this be a problem for FreeBSD using ZFS, too?
> Why would Linux have a problem and not FreeBSD?



Found a detailed discussion of the ZFS CDDL / GPL issue at Conservancy. 
For his wording, I guess Linus referred to this.


----------



## Hakaba (Jan 26, 2020)

I am not an expert but I like the idea that maunchd or systemd have to be the process with ID 2.
(https://forums.freebsd.org/threads/systemd-vs-launchd.44973/).


----------



## Phishfry (Jan 26, 2020)

weberjn said:


> Assuming Linus Torvalds' misgivings concerning Oracle are valid, could this be a problem for FreeBSD using ZFS, too?
> Why would Linux have a problem and not FreeBSD?


Because the OpenZFS license is CDDL. It is compatible (legally similar) with the BSD 2Clause license.
The CDDL license is not compatible with GPL2/3.






						A discussion on combining CDDL and GPL code [LWN.net]
					






					lwn.net


----------



## mark_j (Jan 27, 2020)

Hakaba said:


> I am not an expert but I like the idea that maunchd or systemd have to be the process with ID 2.
> (https://forums.freebsd.org/threads/systemd-vs-launchd.44973/).



If you're talking about restarting failed programs,  why? There are already tools that perform that if you wish. Perp and daemontools, for example.

launchd is a mimic/'enhancement' of SMC from Solaris. SystemD is a mimic of launchd. They all attempt to consolidate various tools into one huge monolith for no other reason, it seems, than they can. It doesn't benefit anyone other than the developers as they scope creep into oblivion. So you might like some of the features of launchd but I'll bet the house's money you'll see scope creep just like systemD if someone decides to use it as a replacement for rc.

When did systemD start? 10 years ago? It's still growing and will not stop until it has all the userland utils (essentially replacing GNU) and boot control.

But that's the Linux way: scope creep and bloat. I hope the same doesn't happen to ZFS.


----------



## mark_j (Jan 27, 2020)

Phishfry said:


> Because the OpenZFS license is CDDL. It is compatible (legally similar) with the BSD 2Clause license.
> The CDDL license is not compatible with GPL2/3.
> 
> 
> ...


And not only that, it seems Sun deliberately designed it that way, taking into consideration the viral nature of the GPL.

The obvious solution is for Torvalds to re-license under BSD. Simple...  But then he'd lose control and that's not in his nature.


----------



## Hakaba (Jan 27, 2020)

mark_j said:


> If you're talking about restarting failed programs, why?


No, no... I am talking about the idea : don't touch the id 1 for supervision or other tasks. Let the choice about what init (id=1) launch. If you want a systemd like features, let init (id=1) launch it (and only it so the id of this tools will be 2).
I am sure that the time of this fork call is not mesurable. But the design is more comprehensive and let a lot more liberty (don't use systemd like, use it for all, use it for specific deamons...)
But this tools exists, that stop the need of systemd.


----------



## yuripv (Jan 27, 2020)

That's just it, Linus the .... doesn't recommend using something for something  Who gives a fsck* 




_View: https://www.youtube.com/watch?v=xVH3PPH4l80_
 who cares.


----------



## mark_j (Jan 27, 2020)

Hakaba said:


> No, no... I am talking about the idea : don't touch the id 1 for supervision or other tasks. Let the choice about what init (id=1) launch. If you want a systemd like features, let init (id=1) launch it (and only it so the id of this tools will be 2).
> I am sure that the time of this fork call is not mesurable. But the design is more comprehensive and let a lot more liberty (don't use systemd like, use it for all, use it for specific deamons...)
> But this tools exists, that stop the need of systemd.



Precisely. There are tools in ports that can accomplish this. Heck, I've got a shell script that's triggered by cron to watch for a daemon and if it doesn't exist it sends me an email. I think sysadmins have been doing this stuff for decades. I personally don't need some monolithic suite of programs with binary files and sets of commands to accomplish a few things I can do in a shell.

Benno Rice, a Freebsd systemd fanboy gives you an idea why these projects are scope creep in the making:




_View: https://youtu.be/o_AIw9bGogo?t=2481_


----------



## CraigHB (Jan 27, 2020)

"Unix is dead" 

Why is that guy a FreeBSD developer, he should jump ship to Linux or Apple since he seems to love them so much.  It's like he's only in it for the drama of hammering on the philosophy of the FreeBSD community.

Anyway that talk was super depressing for me, what a millennial dick.


----------



## Crivens (Jan 27, 2020)

Since this thread has diverged from the original topic, which is out of our hands anyway, and has now arrived at the plunger level, are there objections in closing it up in the comming days?


----------



## CraigHB (Jan 27, 2020)

kill -9


----------



## cynwulf (Jan 27, 2020)

mark_j said:


> He uses that stupid licensing system GPL, so let him deal with it.
> [...]
> He's the owner of Linux [...] He could solve the problem, immediately, by re-licensing the kernel code to BSD-style.





mark_j said:


> The obvious solution is for Torvalds to re-license under BSD. Simple...  But then he'd lose control and that's not in his nature.


I don't think it's that simple.  There are far too many contributors to Linux and you would need the agreement of all of those contributors in order to relicence it.  I don't think it's a case of any kind of ideological adherence to GPL, it's more so that at this point there is no real choice.

Crivens, you may fire when ready...


----------



## Vadim_Mkk (Jan 27, 2020)

CraigHB said:


> "Unix is dead"


Bruno Ruce is right. It isn't depression, Its real outlook for his side,
How sing one singer


> The plastic world won
> the dummy turned out to be stronger


Died  HP-UX, Solaris  and other big rock monsters.
I think that and IBM AIX will died in the near future, inside IBM  - "There Can Be Only One"  - if IBM want to develop AIX - didn't spend $34 billion on the purchase RedHat.
Only the battered and scattered partisans remained in an enemy environment - BSD systems and Illumos 
Some are no more, and distant... others ©


----------



## rigoletto@ (Jan 27, 2020)

mark_j said:


> Apple has launchd, which seems to be the basis for Poettering's systemd and I don't see a lightning fast or particularly stable OS because of it!



There is absolutely nothing wrong with event driven boot managers, quite on the contrary. You shouldn't base your opinion about a technology on amateur
implementation[1] (systemd) and in a purpose built desktop only solution (launchd). Have a look at 'Solaris SMF' and I heard 'Amoeba' also have very interesting ideas in this regards.



Vadim_Mkk said:


> I think that and IBM AIX will died in the near future, inside IBM - "There Can Be Only One" - if IBM want to develop AIX - didn't spend $34 billion on the purchase RedHat.



There are some rumors of IBM willing to get rid of AIX since years but buying RedHat will not help with it at all, because the typical AIX consumer (the POWER heavy consumers, aka true mission critical guys) would never run Linux on their  environments.

[1] just remembering RedHat make a living from support.


----------



## Crivens (Jan 27, 2020)

rigoletto@ said:


> Have a look at 'Solaris SMF' and I heard 'Amoeba' also have very interesting ideas in this regards.



Amoeba is very interesting, but dead for about 20 years now.


cynwulf said:


> Crivens, you may fire when ready...


Roger that. Taking the shot.


----------

