Nice article, it does a good job of conveying just how simple it is to use the OS primitives for secure-ish* delivery of secrets.
I think it falls short in meeting people where they are when they use env files. I appreciate the section at the end that says "if you must use dotenv files", but surely there's gotta be a middle ground where you can still leverage the OS and not lose out on convenience.
I think it could even look like an npm package that helps you set up the service correctly for local development, accounting for the reality that there is likely several projects on a developer's machine and some of these projects are there temporarily.
* of course, there's still all that stuff about environment variables being visible to other processes, so we still need decent runtime infrastructure for envvars like `DATABASE_URL_FILE`, a temporary file where the application can read the secret at runtime. I'd love to see that in Node instead of the `env-file`
That is the same impression I got reading this. I would enthusiastically use any OS-first method if it means one less brittle dependency, but the current usage of environment variable is rather different than what is described in the post.
Where .env files shine is that:
- they act as a declaration of expected environment variables,
- they are project-scoped, which is one big issue with using "/etc" for example
I personally like to set a .env.example for my collaborators to know what's expected, and I use a .envrc with direnv. And to make it more secure, I always have .envrc in my global gitignore so I can't just forget it.
The drawback is that for any non-interactive run (debugger) I have to manually add each variable each time.
I think the point the author is trying to make is dealing with environment variables was a solved problem 40+ years ago on FreeBSD and other Unix-like systems.
And that we shouldn't need to download something like dotenv to address something the operating system should handle.
I disagree that this submission has no value at all or that it should be auto-banned — there is a difference between thoughtless vibe-coding and spec-driven coding, guarded by tests. It seems from the next thread that this project is hopelessly outmatched by the sheer complexity of taking on something as the Docx spec, but this project has value, and for someone, it may be all that they need.
However, I do agree with your point about live debugging. In light of that, I prefer to treat this submission as a curiosity about current model capabilities, and let the authors keep improving this project if they find it worth their time.
Let's be more respectful to the differing goals of people
Oh great, I missed that end of the page. The "Round 2 details" links back to the blog and it is hard to see the FAQ on mobile (needs manual scrolling to the end).
Google search and Perplexity failed when I tried, too. Google search has caught up now (haven't retried Perplexity)
A 41.5mm diameter sounds good. That's a whopping 10mm/20% smaller than my current watch. Should be really neat given the thickness.
Is the Round 2 also going to have screws to potentially replace the battery, like Time 2 does?
Also, while watching the announcement video, I noticed that the pixels are quite a bit more visible on the Round 2 on the same watchface, when compared to Time 2 — on the Time 2, the image is a lot more crisp. Is that a matter of adapting the watchfaces to the bigger screen?
Why no screws when you specifically called out that there ARE screws on the Time and Duo 2s for the sake of longevity of hardware even if the company goes away?
Are you saying there's no access into the watch or that it's more like a traditional circular watch where you can twist off the back?
Dang, I really liked that there were screws on the Time 2. Does that at least mean waterproofing will be better? :p For instance, would it be a good idea to swim with the Round 2 on?
30m (3 bar) basically means splash-proof, not even your stated 1m (activity while submerged, I suppose). Like, 30m is IPX4-5, 50m is IPX6 (very rough equivalence), so 30m is the barest minimum expected from a watch.
I wouldn't care so much about WR for a round Pebble, which I'd wear on nicer occasions. I would care more about WR for a watch that I'd wear at the beach or pool, as a way of getting notifications when not carrying my phone.
But screws might add thickness/weight to the watch, compared to glue.
Out of the box it can transcribe with Whisper or Faster-Whisper, but it can also align audio with an existing human-written transcript, providing time information without losing accuracy. This last feature was something I really needed, and my attempt at building it myself ended up much worse, so I'm glad I found this
I self-host it using Modal.com, as do some other commenters
I think it falls short in meeting people where they are when they use env files. I appreciate the section at the end that says "if you must use dotenv files", but surely there's gotta be a middle ground where you can still leverage the OS and not lose out on convenience.
I think it could even look like an npm package that helps you set up the service correctly for local development, accounting for the reality that there is likely several projects on a developer's machine and some of these projects are there temporarily.
* of course, there's still all that stuff about environment variables being visible to other processes, so we still need decent runtime infrastructure for envvars like `DATABASE_URL_FILE`, a temporary file where the application can read the secret at runtime. I'd love to see that in Node instead of the `env-file`