zipityzi

Yes, I believe it is the local UI. In some interview or statement earlier this year , Eshtek noted the local UI will spawn its own Docker container. It won’t be built into the OS’ core and IIRC, it will be a minimal UI for simple tasks that won’t replicate the online-required Command Deck. AFAIK, no public updates yet—just to expect it in 1.0 and that’s all. Eshtek seems to be one of those “work in silence” projects so hopefully that focus means a polished good product at the end.

Fully agreed; with HexOS 1.0 stable claimed to be months away, this is when communication needs to be clear and simple. I'm assuming (and we all know what that means) that Eshtek uses calendar quarters, not made-up financial quarters. Thus, pieced together from the little I can see: Q2 (current beta) is based on 24.10.x Q3 (coming beta before Sept 30) may be based on 25.04.x Q4 (coming stable before Dec 31) may be based on 25.10.x I agree; Eshtek ought to put all release information into a chronological blog, IMO (or any one source) Some things are only on reddit, some things only in the forums, some things only on the website, some things only in YouTube interviews, etc. Now, I haven't bought the lifetime license yet so maybe those forums are more regimented. I'm waiting to see this communication at least a little more consistent and open.

A month ago on /r/hexos, empahsis mine: If we assume the slower track, Q3 (beta) runs on TrueNAS 25.04 Q4 (stable) runs on TrueNAS 25.10 Eshtek's communication is kind of sporadic; their website ought to be the souce of ground truth for key announcements, like a good old chronological blog.

I suspect it will be Fangtooth (25.04), since the "Q3" update ought to ship in September. TrueNAS has estimated Goldeye (25.10) ships stable in October (10 = 10th month = October). Two theories, at least, I think: Slower: HexOS likely started "Q3" before 25.10 had a public beta. So HexOS builds on the current stable release at the time, which was 25.04. So most HexOS releases will lag behind the TrueNAS release. Faster: HexOS, by virtue of partnering with TrueNAS, has access to the 25.10 builds earlier than we plebians. That means HexOS starts with an earlier non-public TrueNAS release. I'm leaning towards the slower version, as that removes some variables and is easier for HexOS. And, for us, hopefully it means fewer bugs as we'll get a slightly maturer version of TrueNAS, not unlike TrueNAS Enterprise which also lags stable now. Hopefully we get the official answer in the next two weeks.

Thank you for sharing this very detailed guide. I've been wanting to set it up and it seems pretty easy to follow! // HexOS ought to have a simplified app UI for Tailscale because it seems painless. Ideally, it's not a "metered services" that HexOS will charge for, because Tailscale uses your own bandwidth and its free tier is already fantastic.

Thank you for your reply, @Mobius. That does make sense. To your final note, hopefully by stable, if we manually create these vdevs in TrueNAS, they can play nicely with HexOS. — I agree: I believe folks recommend the special vdev to have the same redundancy as the data vdevs; if it were to be added, hopefully that recommendation could be prominent. I've heard mixed things about performance: for many-file directories, it can feel snappier, which is what I hope. SLOG: ah, I had another angle. My main interest are a couple of wired Macs on our network as Macs write to SMB synchronously (straight to HDDs), without fast RAM-first writes like Windows machines. But with an SLOG, Macs write to this faster SLOG vdev, allowing the transfer to complete faster. So with an SLOG, Macs have virtually identical write performance as Windows. But without the SLOG, Macs write a little slower. We definitely use a UPS; it's a solid investment for data integrity as you get PLP for the whole server! A great recommendation.

Hello! Are there plans for HexOS to allow users to use (mirrored) SSDs for ZFS' tiered storage optimizations? The main three uses I'm thinking of: Enable high-endurance mirrored SSDs to accept synchronous writes (SLOG) Enable mirrored SSDs to store all file metadata (special vdev) Enable mirrored SSDs to store all small files (special vdev) While I'm sure popping into TrueNAS (for those with that experience) would work, I think implementing these directly in HexOS would be quite beneficial even for consumers with many small files and / or macOS devices. While not all performance-based vdevs are helpful in most scenarios, these would be great, especially the special vdev for small files, e.g., use the ultra-fast random access of SSDs for video editing project files or documents (special vdev) and especially the SLOG vdev for macOS SMB writes (always sync writes). Of course, in some far and away future, HexOS would identify when these vdevs would significantly improve performance, but manually turning them on & testing them out would also be neat through HexOS. I'm intentionally ignoring L2ARC, which requires much more careful hardware selection & tuning to get any benefit.