That’s a good idea I hadn’t thought of.
I think it’s a mistake to think of TrueNAS as “another Debian system.” It’s TrueNAS. It’s an appliance OS, and iX is increasingly locking it down to prevent modifications iX doesn’t approve of (which is most modifications). Expecting it to work like any other Linux distro is likely to be a path to frustration.
That’s exactly the point… If it’s an appliance OS, a standard folder is expected. Else we should expect to have a normal Debian behavior.
The idea of such a standard is to have it simplified for new/young drivers as @jct mentioned and have less confusion.
Apart from that; once we see the Debian behind it - it’s hard to unsee that… 
I fully agree with “this is an appliance” concept, but the attempt is to make it a better appliance with best practices defined. Let’s try to make it simple for all…Cheers.
…only if running additional “custom” software in the base OS is expected. IMO, it isn’t.[1] I expect iX’ answer if they were to give it (which, to my knowledge, they haven’t) would be, “don’t do it.” And if that’s their answer, of course they won’t define a standard location for something they don’t recommend in the first place.
This is my observation of the way it is, not my opinion of how it should be. ↩︎
Hey, I’m very excited to see this discussed again!
IMO it’s very timely to the point of being almost a one-time opportunity. iX and the community can choose to get ahead of another whirlwind schism of shifting/conflicting workarounds for beginners. And to better illustrate value of the latest strategic pivot.
I’m ready to argue that this is actually the correct answer from Fangtooth forward. The base OS is a protected resource; most if not all shell access can be satisfied in one or more user-owned, fully customizable userspace environments.
Experts can and should have spirited debates about how to best flavor those environments! Just not the base appliance/hypervisor. That way lies madness.
Meanwhile, even beginners could safely spin up, tear down, familiarize, and pursue all the various suggested approaches — without conflict or consequence. They can learn while doing; seeing results and safely iterating.
Specifically: I ask that there please be a page in the official iX documentation illustrating one easy golden path to create and tweak a simple Debian userspace.
I say Debian, but only as a default for anyone getting started and seeking guidance. As with a default shell: there are other alternatives but here’s one that works well.
Emphasize the ease of starting over at will, or of creating and using more than one.
Then each and everywhere iX felt necessary to admonish people never to use apt on the base OS: keep it simple. Link to that reference model. Present the solution; not just the dead-end.
Important: This page should not attempt to describe all of the features of Incus. That belongs somewhere else. This page should focus exclusively on the idea of a place for your stuff, where everything goes and most of it survives dramatic upgrades and maintenance.
Eventually, maybe shell access should bring you directly to an environment like this? But for now and if done right, just documenting this narrow use case could help tremendously.
Those of us on the outside supplying non-containerized scripts, tools, and services: we might choose to direct beginners to that same page. Getting everybody up-to-speed on basic installation, so they can focus on the specific project in question.
Up to this point, users have needed to pick from a confounding expert slugfest, just to get started with any one tool. It’s not clear how to even gauge the risk that one tool’s custom installation process might somehow preclude or complicate later approaching another tool with its own custom process. Nevermind their security repercussions.
Overall, there should be a whole lot less foot-shooting. Whether as a solo or group activity.
I humbly suggest that people both inside and outside of iX have been underestimating the depth of user frustration and opportunity cost, traceable to this specific pain point. It manifests in a number of ways, but IMHO most compute-related TrueNAS headwinds start from here.
I phrased this part especially poorly. I regret and apologize for my insulting tone.
I do not believe that anyone is unaware of the significance of any problems at hand, nor of any frustrations users encounter. I had intended to say that many of these concerns seem to be attributable to this shared root cause — more so than I see being discussed.
In my thesis, if you came up through FreeNAS then you have a perspective that differs almost profoundly from that of newcomers interpreting the SCALE literature. Longstanding tensions between “plugin” apps and “jail” environments played out especially poorly in SCALE’s shifting converged app strategies. We talked past each other with no clearly stated jail strategy until recently — and maybe not enough introduction to help make sense of it for newcomers today.
I notice that people don’t tend to leave TrueNAS for, say, Ubuntu Server but for Proxmox. Or they put TrueNAS inside Proxmox for similar reasons: it doesn’t “feel” as if TrueNAS alone provides them a healthy shell environment for their own stuff.
At least as of Fangtooth, TrueNAS very much does provide those environments, with that flexibility. As with Proxmox: it’s just not at the base hypervisor layer. And I’m not sure that’s getting across yet.
I wish I’d just said that.
