(#2tjsjuq) @prologic I just set up a Yarn instance from scratch and, honestly, I don’t think a `yarnd setup` is needed. 🤔 I followed the instructions here and they were simple enough: It needs a little polishing (for example, it says `COOKIE_SECRET` is optional which it isn’t), but it was a good experience overall. Maybe it’s just me, but I prefer reading installation instructions. And I believe that *not* having something like `yarnd setup` nudges you (the author) into keeping those instructions short and concise. Whereas the existence of `yarnd setup` means that you can cram everything and the kitchen sink in there, because it’s convenient. That can lead to a convoluted setup process – and me, the user, does not really know what that command really does, which is something that I, personally, don’t like. 😅

(#2tjsjuq) @prologic I agree with @movq. Good documentation is better than an interactive setup process. My difficulties (#isyb2aq) were because I was just doing it for testing and I wanted it running as quickly as possible. If I was running it in a production capacity, I would read through the documentation. If you're trying to make non-technical people set up their own Yarn pod, that's probably (unfortunately) impossible. Management software like Sandstorm make it "as easy as installing apps on your phone" (direct quote from sandstorm.org) and most people still pay Google to store their photos. I remember you were trying to do paid hosting for Yarn pods in the past. That could work, but as I'm sure you know it's difficult to convince people to use this over X or Facebook, let alone host their own pod. I think it's going to stay a small community of fairly technical people for the foreseeable future.

(#2tjsjuq) Thanks@movq @mckinley This is great feedback! I'll tidy up a few things today! If there's anything else not super clear ot obvious, please let me know. Maybe you too @bender if you can remember 😅 -- Yes yes I know there's still some issues you have with the cache behavior, etc (_on the roadmap_).

(#2tjsjuq) @prologic Newcomers might have a little difficulty because just “installing” a Go compiler is not enough – you also need to add `~/go/bin` to your `$PATH`, at least I did. I’m not sure what to do about it, though. 🤔 This doesn’t really belong into Yarn’s setup guide and it’s mentioned as one of the first things in the Arch wiki, for example, but still … To newcomers this might look a bit like a broken build process: ``` openbsd$ gmake server /bin/sh: minify: not found /bin/sh: minify: not found /bin/sh: minify: not found gmake: *** [Makefile:84: generate] Error 127 ``` Maybe extend Yarn’s guide just a *little* bit, like: “… be sure to have Go installed and set up properly, e.g. env vars are set …”? Maybe that could point readers into the right direction. 🤔

(#2tjsjuq) @prologic One minor detail: The Makefile wants to run `date -Is`, which doesn’t exist on OpenBSD. Not sure how relevant this platform is for you, though. 😅 I haven’t come up with a portable solution yet. `date '+%FT%T%z'` is the closest approximation that works on both GNU and OpenBSD, but it doesn’t include a colon in the time zone offset, so it’s `0200` instead of `02:00`. 🤦 I’m not sure if this is ISO8601 compliant. And it’s still not POSIX. 🤦 Well, I tried. 😂

(#2tjsjuq) @movq I'm open to some other method of consistent "build date" 🤔

(#2tjsjuq) @prologic Does one need a build timestamp anyway? That's an enemy to reproducible builds. Maybe just use the commit timestamp? That would work at least for official releases. It would be off for dirty working directories during development, though: `git show -s --pretty=format:%cI`

(#2tjsjuq) @lyse I _think_ you were the one that originally came up with this `BUIDL` thing. Was it always suppose to be the commit timestamp? 🤔

(#2tjsjuq) @prologic Oh, was I? I don't recall any of that. But who knows. ;-)

(#2tjsjuq) @lyse Anyway fixed 👌