In fairness to OMV, zfs was never its primary focus. Being much closer to pure debian than SCALE, naturally it defaults to using the debian bookworm stable kernel which requires the use of the zfs-dkms when installing the necessary zfs packages. OMV is not designed around a strict “appliance” model. The greater freedom to install packages/community plugins allows the use of an alternative proxmox kernel (itself based on an upstream Ubuntu kernel), if you wish. I don’t see these facts alone as a reason to disregard OMV for zfs storage, but there others that might not make it a first choice amongst alternatives.
2 Likes
There’s a lot of unnecessary gatekeeping and elitism in this thread.
Computing wouldn’t be where it is today if it wasn’t for someone reducing the barrier to entry. There was a time when the only computer you could access was the one in the basement of the company you were fortunate enough to work for until someone made something cheap and small enough to fit into the home, making it financially accessible to many more people.
Then someone put a nice UI on it and made it technically accessible to many more people.
Then someone wrote their own kernel, making it legally accessible to more people.
The list goes on and on. Every time someone says something about users needing to learn some technical jumbo, or deriding someone because they prefer a GUI over a command line is missing the point entirely: Nothing is so technical or so complex that it stays inaccessible to the layman. Not even ZFS.
I suspect this is entirely the point of HexOS - to simplify setup and guide users to avoid these pitfalls. TrueNAS has the capability to be incredibly powerful and versatile, but the barrier to entry is high - and that’s not a good thing. This is fine in the enterprise world where you should know your shit from the technical side to the procedural and policy side but for home users there’s no reason that can’t be simplified and straightforward.
I’m interested to see what the business model will be - but would a subscription be so terrible? There’s lots of comments here suggesting that this will encourage even more poorly written support posts on this forum and that’s going to be an issue, but a subscription means you can have a paid support model with people who’s literal job it is to support these novice users. That also gives the business an incentive to make the UX better to guide users away from improper setups to reduce the support burden. It seems like a win-win-win to me: Novice users get support, HexOS gets a revenue stream and TrueNAS gets far less noise.
It doesn’t seem like such a bad idea to me.
8 Likes
Given the tacit support / cooperation / etc between HexOS and TrueNAS, I’d like to think that the feature flag set will remain the same between the two but one cannot count on it unless the two entities behind them pledge to remain compatible.
We see this even with SCALE vs. CORE where present Dragonfish pools are no longer compatible with CORE 13.3.
HexOS could very well become the beta test playground that TrueNAS has always wanted without the potential commercial blow lack in case something goes terribly wrong with a new feature. See docker, for example.
form a user perspective, the answer is likely lots of backups, preferably in a different file format. 
I completely agree that the learning curve for TrueNAS is super steep compared to the entry level competition from ReadyNAS, QNAP, and Synology. The big delta is the setup process, where much of the complexity is abstracted away initially and if you really want some of it back, you can add it back later.
TrueNAS doesn’t have a setup wizard, it allows settings to be used that won’t work, or pools that will likely self-destruct with time (single-drive Vdev getting added to the pool, anyone?). So from that perspective, I see a lot of growth potential.
How to fund it is a critical question. I really dislike subscription models since the arguments for subscriptions are frequently not borne out in the marketplace, see the crummy evolution of products from MS, Adobe, Autodesk or Agile Bits. Instead, the money is used to buy back stocks and pay dividends. Not a benefit to users, is it?
Especially in the context of a critical piece of infrastructure like a NAS, I would shy away from a platform that cannot work unless my node(s) occasionally get(s) the ok from the mothership. That creates a single point of failure that I’m super uncomfortable with.
I would also find a subscription model somewhat ironic in the context of the advertised “you control your data” by HexOS.
2 Likes
It used to, earlier in the FreeNAS days. Wonder why that went away.
I’m not sure if it allows this any more; at a minimum it complains loudly if you try.
1 Like
I imagine it took a lot of time and effort to update the wizard to keep up with changes to the middleware? It’s one of the lovely aspects of TrueNAS - the product keeps evolving - but said evolution requires an attention to detail that is sometimes lacking.
For example, see the documentation for Dragonfish scale still mentioning a non-existent SMB auxiliary parameters window in the SMB dataset share configuration control page.
A lot of things here work mostly very well under the hood but synchronization between documentation / help can be out of date by a few months unless someone alerts @kris or whomever that there is a incongruity between the UI in 24.4.1.1 and the associated resources page(s).
Now imagine trying to accommodate these kinds of changes in a wizard. The iXsystems team would have to do an even better job of synchronizing changes across multiple teams throughout the TrueNAS development universe. That takes a lot of resources and management time.
I reckon HexOS will be the trial balloon towards developing a less intimidating setup experience and if the path works well, then it’ll be something that iXsystems can consider adopting. A lot of work goes into crafting a usable, intuitive UI.
I submitted a PR to fix this oversight literally 10 minutes before reading this comment…
More generally though, while we do our best to stay on top of development changes, some things will slip through the cracks.
In addition to alerting someone on the forums here when you notice something like that, you can also use the Feedback button on the right side of the Docs Hub to point us at a needed update or use the Edit Page link at the top right of any article to propose your own corrections.
6 Likes
I mentioned it a week or two ago when I noticed two unhappy behaviors as part of my CORE → SCALE transition. One, SMB showed itself as running (when it wasn’t) secondly, the SMB auxiliary commands that worked in CORE didn’t work in SCALE and caused the middleware to crash spectacularly.
The point is not to elevate the issue of documentation not being kept up to date, it’s simply an illustrative example of two teams (documentation vs. development) being out of sync. If iXsystems were to develop a wizard, changes to the UI / middleware / whatever would now have to be documented / communicated / implemented across three teams.
I imagine the complexity of developing a wizard combined with keeping it up to date across an iterating base is why iXsystems decided to stop trying to keep up its development. I could also see the argument re: prioritizing resources towards the UI and middleware vs. a process that most users only touch once every couple of years.
1 Like
To be fair, your auxiliary parameter didn’t work in Core either. It was 100% invalid for samba in general. It slipped through validation and samba config in a file is somewhat more forgiving of this. Samba config in registry flat-out rejects it. Your issue is already addressed for 24.10 (by removing some of this cluster-related configuration backend).
1 Like
… and therein lies the rub, no? Even though the parameters were unacceptable to TrueNAS Core, SMB still started, still functioned, and never displayed an error message… for years. From my POV, it seemed to work. Only when the system transitioned to SCALE did the error of my ways become apparent, but not in an intuitive way either.
SMB shouldn’t claim to be running in the UI if it isn’t. A bad config file should be called out as such in plain English, not a batch of middleware parsing problems that non-programmers like myself do not know what do with other than copy, paste into google and then pray that someone else has had the same problem.
1 Like
See, for instance, the Corralpocalypse disaster. I was there, people got scared. Fortunately, the changes were not destructive to data.
Edit: People got scared, I got scarred.
4 Likes
Then you should have at least one report already since I reported the aux param thing weeks ago using the feedback form in the docs.
2 Likes
I do believe that’s what prompted the first part of Dan’s post …
3 Likes
“hey, you dropped this 
”
3 Likes
I thought IX had said they intentionally disallowed aux params as people could mess too many things up and they didn’t want that. Something like several months ago. We’ll see how the bug report goes!
1 Like
No, there really isn’t. What you’re misperceiving as “unnecessary gatekeeping and elitism” is a combination of a few things:
- Recognition that Linus of LTT has a laughably-poor record when it comes to technical competence in general, and TrueNAS in particular
- This wouldn’t be an issue if he took the posture of a student. We’ve all been n00bs before, and still all are with respect to something. To briefly risk speaking on behalf of the community, we don’t have a problem with someone who’s ignorant, but trying to learn. But we do have a problem with someone who’s ignorant and yet presents himself as an expert, and Linus is such a person[1].
- Recognition that good NAS software design requires a great deal of effort, leading to questions of whether this team have done the work (or are well-funded enough to do the work) necessary to result in a quality product
- Recognition that properly configuring, operating, and maintaining a NAS takes a fair and apparently irreducible degree of technical knowledge and skill, with attendant concern that EasyNAS HexOS is going to prevent such proper administration. There’s only so much complexity you can avoid by hardcoding sensible defaults.
Put simply, you’re confusing recognition that these things aren’t simple with a belief that they should not be simple.
I don’t think any of us are hoping for the failure of HexOS, but I think it’s safe to say most of us are skeptical. And that’s neither elitist nor gatekeeping, necessary or otherwise.
That’s far from the only issue with him, but I’ll leave those for others ↩︎
7 Likes
i agree with @Dan, if hexOS can dramatically reduce complexity for new users while remaining performant re: data security, backups, docker, whatever then iXsystems has a winner on their hands that they can emulate.
I don’t consider the folk here elitist gatekeepers, quite the opposite. If they were gatekeepers and/or elitist, they wouldn’t bother contributing resources, provide free tech support, and so on. Rather, it’s a very caring crowd that helps each other.
So, I’ll reserve judgement until when the product ships. The question of how it will be funded on an ongoing basis is quite relevant to its long term health, and as yet unanswered.
1 Like
No, TrueNAS is the primary vehicle. BETA testing is done via this Community (thank you all). HexOS will depend on a well-tested version of TrueNAS that is suitable for non-IT users. They will probably operate as a Conservative user in our Software Status ranking and will control software updates. Software Status - TrueNAS Roadmap - Open Source NAS Software
1 Like
Interesting. Makes sense. The setup, docker, and like system support of a new user will be interesting to compare to TrueNAS. And there may be a thing or two worth emulating if the hexos UI manages to make the learning curve less steep.
It’s wild that so many people in this thread are acting like Linus is the one actually writing code for this new OS.
The dude wrote a check, that’s all.
7 Likes