3 ms·

> It saddens me, that the core development path in BSD was not able to sustain being the "reference" model for a wider community. Could you explain? FreeBSD wa

by gh02t 8y ago

> It saddens me, that the core development path in BSD was not able to sustain being the "reference" model for a wider community. Could you explain? FreeBSD was not the reference implementation of ZFS, illumos was. ZoL is still tied up in the OpenZFS project (as are illumos and FreeBSD), this is more a matter of rebasing onto the subproject where more development is occurring. As it was, FreeBSD's implementation was already using a Solaris/illumos compatibility shim, and it sounds like switching isn't that much work.

ggm 8y ago
Oh, I misunderstood. I thought the input back into Linux ZFS grew out of the (Free)BSD work. If its two independent OS trees both referring upstream to Illumos, its a minor moment. What does the solaris compatibility shim do in the end, which couldn't be done direct in the codebase? I don't like shims, it feels like the linux compatibility ABI moment where something gets added and the shim drifts, and then you can't do eg DRI any more because "they changed how it worked and we didn't catch up" But, thanks for the cluestick hit. If this is just flavour of ice-cream from the same truck, I'm less worried.
- simcop2387 8y ago
  The shim, as I understand it, for linux is there to both handle some licensing differences and to also translate between Linux's io subsystem which isn't going to be turned into Solaris' nor will ZFS's be turned into Linux's IO subsystem directly. They're basically compatible but have different ways of doing things so it results in needing a shim to handle things.
- gh02t 8y ago
  I don't know a lot about it, but my understanding is that the shim is pretty thin, there to translate some slightly different syscall conventions. Compatibility shims done well (minimal to no overhead) can be very beneficial, allowing separate projects to share more code directly. On a separate note, illumos is a really cool project. I hope this transition (and apparent reduced activity in their development on ZFS) is not a symptom of the project losing momentum. My first experiences with a computer were on SunOS and early Solaris, and illumos is the the [open source] heir to that throne.

by gh02t 8y ago

ggm 8y ago

Oh, I misunderstood. I thought the input back into Linux ZFS grew out of the (Free)BSD work. If its two independent OS trees both referring upstream to Illumos, its a minor moment. What does the solaris compatibility shim do in the end, which couldn't be done direct in the codebase? I don't like shims, it feels like the linux compatibility ABI moment where something gets added and the shim drifts, and then you can't do eg DRI any more because "they changed how it worked and we didn't catch up" But, thanks for the cluestick hit. If this is just flavour of ice-cream from the same truck, I'm less worried.

simcop2387 8y ago
The shim, as I understand it, for linux is there to both handle some licensing differences and to also translate between Linux's io subsystem which isn't going to be turned into Solaris' nor will ZFS's be turned into Linux's IO subsystem directly. They're basically compatible but have different ways of doing things so it results in needing a shim to handle things.
gh02t 8y ago
I don't know a lot about it, but my understanding is that the shim is pretty thin, there to translate some slightly different syscall conventions. Compatibility shims done well (minimal to no overhead) can be very beneficial, allowing separate projects to share more code directly. On a separate note, illumos is a really cool project. I hope this transition (and apparent reduced activity in their development on ZFS) is not a symptom of the project losing momentum. My first experiences with a computer were on SunOS and early Solaris, and illumos is the the [open source] heir to that throne.