zipityzi

That was a interesting read. The app issues seem tricky and a little length. The power supply monitoring was great. This would be a great feature to be integrated. For quick setup, I use HealthChecks.io and it'll ping me on Telegram when something stops sending its pings. But for now, HealthChecks.io is free and easy (it will require going back into the TrueNAS UI for the cron job, though).

This would be a pretty neat feature, especially for big ingresses, where I usually need to copy to NVMe pools → work / edit / build → export back to HDDs. Unraid does something similar with its cache pools & "mover", so there is precedent for something like this to be added to HexOS.

Agreed. For me, UPS support is important, especially as the TrueNAS UPS service is good enough for today. Graceful shutdowns are the ideal. IMO, UPSes help for more than just utility blackouts / brownouts: circuit breaker trips (e.g., vacuum on the wrong outlet at the wrong time) someone unplugs the wrong plug (e.g., they thought it was another device, but turned out to be the NAS) ZFS does really well with power loss due to CoW, but reducing the # unexpected power loss events is good, especially with spinning rust, non-PLP-backed SSDs, the myriad of hardware combinations not uncommon in DIY consumer NASes, avoiding the temporary loss of in-flight TXG writes (~5 seconds).

Seems like everyone here already explained this kindly enough. Here's my last shot. To most, there is no "great product" without quality & clear documentation, change logs, tutorials, release cycles, roadmaps, etc. What is obvious to folks that actually self-host or store critical data, except the most basic users: it is painfully annoying to use any allegedly "great product" where the developers "are too busy working on the OS" write their changelogs with known issues, compile the hundreds of details + limitations in their product with solid documentation, somehow believe every user "ought to just know" how to fix critical OS errors, or thinks "our product speaks for itself". Nobody here should be so enthusiastic to forget HexOS predominantly works on TrueNAS API, but I am continually surprised in this thread. The quality of an OS is not purely in its code. TrueNAS, Ubiquiti, Unraid, etc. must all do their detailed docs, changelogs just for fun, lol: "Nobody needs that. See, the code we wrote, this product, it's beyond mere words. Oh, bugs or limitations? You tell me". Quality communication and a quality product are not an either / or proposition for a NAS OS. In the end, most users will continue to have very different expectations for HexOS. Cheers, friend. 😀 Now, if you also believe marketing was the impetus of this thread & these comments, welp, now I get why others stopped replying. I think this thread has run its course.

So the rest of us could move past the marketing. That tracks. I value at zero how many views an influencer/investor got versus the documentation, change logs, tutorials, release cycles, roadmaps, etc. Thanks for clearing that up. 😀 Anyone who's used a new platform, and especially a new "OS" like HexOS, knows that communication with users is paramount for an "amazing" product. No need to believe me, just ask Eshtek founder's old gig and their Unraid Docs and Unraid Release notes. ^^ that is what we ought to advocate for the 1.0 launch, not more influencer/investors making marketing videos. Clear, thorough, consistent communication with users goes a long way to building a strong reputation, especially beyond release and especially with paid software. Even documentation-light, heavy-on-the-simplification Ubiquiti knows it has to be upfront: limitations, bugs, workarounds, etc. are commonplace on any NAS, e.g., Ubiquiti Drive Features & Configuration — Ubiquiti Help Center. // Anyways, excited to see what Q3 brings tomorrow on Monday. Really curious how much they've improved since Q2, especially how feature-complete HexOS is before the 1.0 update. Are we now mostly an RC with just bug fixes, cutting features for 1.0 to meet the deadline, or crunch time to get it all done and hope for the best? Let's hope for great news.

It misses the point, IMO: users on the HexOS forums in the beta stage are clearly very interested in HexOS. The # of views an influencer has is meaningless.. External marketing is less relevant to users on these forums: we're already here. Eshtek's communication choices with users is what drives forum posts like these. Eshtek, like all software companies, will have its early success based on its reputation among its users. Another “world-class” influencer marketing campaign will mostly hit non-users.

"world-class", "amazing", "frantic growth" are curious to read on the company's own forums. HexOS is much better understood as a software Kickstarter: influencers that hardly use the product, ordinary folks buying primarily because of a discount (not because betas are actually worth $100), promises of improved communication after slow updates, unexpected delays, scattered updates, etc. Many "make software accessible" enthusiasts do expect things ike reliable software with regular bug fixes; reliably-timed updates; unified & direct communication with users (thorough changelogs, docs, tutorials etc.) etc. HexOS is not an alpha nor an open-source project waiting for volunteers; these deliverables ought to be coming soon with at most ~90 days before 1.0 ships. How Eshtek communicates with users (not with the public) about Q3 will be a great signal of how things are shaping up, what has improved, and what has not. Like everyone, excited for the Q3 release on Monday.

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.