This conversation began in an announcement thread, which was closed because this was off the topic of the original announcement. For context, here's where we left off:
And then:
There then some discussion about using ZFS on USB, and it seemed that the usual warning against using ZFS on USB was against using USB SATA hard drives, since the USB-to-SATA bridges are a bit problematic.
I'm a little confused. In the current (ISO-based) model, it's easy to roll back to the previous version if there's a problem with an upgrade. How will rollbacks work under the new model?In any case, starting with 9.3 there will be no more point releases. There will be updates you can apply via the update manager, but new ISOs probably won't happen except on major release boundaries. With any luck, 9.2.1.7 will be the last point release FreeNAS users ever see. :)
Also, how will we be able to update file servers that aren't connected to the Internet? Even the documentation notes that "In many cases, a FreeNAS® configuration will deliberately exclude default gateway information as a way to make it more difficult for a remote attacker to communicate with the server."
Will every new install have to download a bunch of additional patches as soon as it starts up?
Perhaps I'm misunderstanding, but that seems a strange example to use. Apple does in fact release point releases.You're thinking old-school. When a user installs OS X "Mavericks" (and the use of a name vs an arbitrary number is intentional) they don't think about point releases. They install something with a name, and then when the update app says "Hi, we have updates for you" they just indicate their willingness to apply them (or not). ... we don't want users having to know or care which "point release" they're running anymore, just that they're up-to-date. That's the value of not having point releases. To anyone who's not a developer or skilled with git, they don't have any real meaning.
Yes, they release interim updates to various components, but then they release a point release that rolls up interim changes into a single (presumably well-tested) package. That's why they're up to 10.9.4 and testing 10.9.5. I go to "About this Mac" and right under the "Mac OS X" title, it says "10.9.4". In the App Store it says the current version is 10.9.4.
And even git has the notion of "tags" so that it's clear when something is released.
I can definitely imagine some benefits to allowing individual components to be updated more easily (and perhaps without rebooting), but I'm having a hard time seeing how more frequent updates are compatible with the notion of a stable server that changes relatively infrequently? This seems like you're inviting a configuration management nightmare.
I must be missing something, but what? What's the actual motivation for going to all this effort? The ability to verify the authenticity of packages?
And then:
That's a nice solution. Will it still boot off of USB stick like that, though? (I didn't get the world's fastest-writing USB stick, since I didn't expect a lot of writes to the boot device...)9.3 will use ZFS in the boot device, which solves the rollback issue via snapshots
Ah, that makes sense. Is the plan for "updates" to be only security updates then? It makes sense to make those easy. And then configuration management is relatively easy, since only full releases have different features.As far as I know, the goal being pursued is to allow easy and painless application of security patches (feature patches being still taken care of during beta testing - at least the majority of them).
One thing people do care about is uptime and whether the pending updates warrant taking the machine or services down. How will people be able to do that (particularly with an isolated file server) without some sort of human-readable version number or timestamp?
I'm still curious how this will work both in terms of an initial install and then subsequent updates if the file server doesn't have access to the Internet.
There then some discussion about using ZFS on USB, and it seemed that the usual warning against using ZFS on USB was against using USB SATA hard drives, since the USB-to-SATA bridges are a bit problematic.