Knew you'd get comments asking why nix is important to the setup. I like it for things like this as well.
Shell scripting by default has terrible isolation. But the way Nix puts shell scripts together, you can be confident that a script's own PATH only contains what it needs to, which is a nice guarantee to have.
I don't see what nix is doing for you? There's vim, absolutely, coreutils (though I don't immediately see anything GNU-specific), and a tiny wrapper script that happens to be written in flake.nix but could trivially be factored out. I don't see anything that I wouldn't expect to run on, say, OpenBSD if you installed vim.
This is a pretty poor example for a few reasons, but the idea is that anyone get can a shell with the tool fully installed along with all its dependencies, with a single command:
Sure; I'm typing this comment on a NixOS machine in a browser controlled from a flake I wrote myself - I get using nix and flakes in general. It's just that this particular case seems like such overkill that it actually seems like a weird tradeoff even if you're used to flakes.
One area that is especially a massive win is projects that cross multiple ecosystems. So like, C++ project with some Python bindings and a Typescript frontend? Setting up that dev environment is often a nightmare but Nix makes it trivial and highly reproducible.
Yea I don't see Nix doing much here particularly, but for me I typically would do something like this to make the system as consistent as possible over a long period of time without being actively maintained.
I guess this does ensure the key `journal` command works exactly the same because the dateutils binary will stay locked to the version in the `flake.lock`.
I would have assumed that nvim would also be locked because that's where I would expect more possible breaking changes with the existing special config.
With little tools/projects like these I could easily see months-years before it would get any active attention from me again (or simply I wouldn't be using it; so it doesn't matter).
I was somewhat expecting that the flake would include nvim bundled with the vimrc in the folder.
You could then just open nvim in the `nix develop` environment (or even use something like direnv to activate it when you cd in) and have a minimal journaling environment
Yeah, if it included ex. nvim plugins then it would make more sense to me. It's just this particular combination is for installing tools that I struggle to imagine aren't default-installed everywhere, and version-locking some of the most stable programs I've ever used (though I guess neovim might make breaking changes?). Honestly it strikes me as most useful as a 'hello world 2.0' flake demo.
author seems to be the type to follow tech trends and use them to signal "coolness" - people like that use these absurd stacks because its niche, not for any actual benefit
There is also a `-b` flag to get it back in to the shape you'd expect from cal. I find the week column easier to read in that form:
w| Mo Tu We Th Fr Sa Su
31| 1 2 3
32| 4 5 6 7 8 9 10
Perhaps worth noting that ncal's -w is ISO-8601 compliant¹, which may surprise some people around new year as week numbers can reset in December or January.
[Said as someone who aliases cal to "ncal -wb" mostly just to get the correct first day of the week for their locale.]
So, I've been keeping a journal for 17 years, off and on. I don't know anyone else who does it my way, so here's my method.
I made a dedicated email account just for the journal. I personally chose gmail but if you distrust google you could use any other provider including self-hosted.
At the end of the day, or when I feel like it, I log in and email the account from itself with a message about whatever happened that day and whatever I'm thinking or feeling, and use the date for the subject line, like "August 12, 2025". I never, ever send emails to anything else from that account nor connect it to anything or use it for anything else. It is a total island.
The result is 17 years of easily-searchable journal, password-protected, backed-up, accessible from anywhere that has internet, can't be "lost" like a physical journal (yes I know I'm trusting google, but again, go self-host if you're worried about that), can't be "found" by someone looking through my things.
I can't even tell you how much value I've gotten out of it. You forget things you don't even know you forgot. So many little moments and days in life. You'll be shocked at the things you used to think and feel sometimes. You'll be shocked at whole magical days that you haven't thought of in years and years and likely would never have thought of again. It's a record of me changing over time and the phases I've gone through. I can't recommend it enough.
And it doesn't take much discipline, either. It's not something I "have" to do. I do it when I feel like it. There are years where I have only 25 entries, and others where I have 200. It depends how much I felt like writing. I find it spikes in years where I'm feeling very emotional, usually during bad times. But I've written down many great days too.
I love this take. I do something similar, in that my journal is completely isolated
For journal entries I record voice notes. I can do it quicker, and I can do it while I'm e.g. driving or walking. I feel that I capture a bit more emotion with it too. I've been doing this for about 20 years, but only in the last year have I been writing a python application to organize and transcribe the notes.
No. But editing a handwritten journal would hardly be any easier. It's a matter of what features you care about, I guess. I have never needed to edit past entries - that would be historical revisionism. It's not a feature I personally need for my journal. If I cared about that for some reason, I suppose I might use a different method.
If I realize I forgot something from yesterday, I just add it the next day.
I've seen it quite a bit on BlueSky with some devs I follow. It's a social git host built on-top of ATProto (The underlying tech of BlueSky): https://blog.tangled.sh/intro
Nix always felt like an OS on the blockchain. It's fine if you value verifiability above everything, but becomes very burdensome if you find yourself tweaking your dev environment often. Still, I think it probably teaches good discipline.
I've found NixOS is fantastic for evolving my environment. Update `configuration.nix` and then `sudo nixos-rebuild switch`. Done.
What kind of "tweaks" are you doing? You could use `nix-shell` to try out a new environment. If you like it the environment, you can make it declarative by creating a `shell.nix` file.
> Nix always felt like an OS on the blockchain. It's fine if you value verifiability above everything, but becomes very burdensome if you find yourself tweaking your dev environment often.
With Nix, "dev environment" can be scoped to be specific to a project. Where on a typical system, you might install a compiler & libraries, with Nix you can describe the development environment in isolation. (Dev Containers uses containers to similar effect).
I'd rephrase your comment as: NixOS is anti-practical. Rather than just changing a config (& restarting a service), you have to change a NixOS config, rebuild that, & switch to the updated config. -- I'd say NixOS (and Nix) support the mindset of "put in all the effort up front now, in order to save effort later".
If someone's written a nix-shell or devenv file for a project, then no further effort is required to get a working dev environment setup. (Devenv is notable for nicer DX over docker-compose for things like "services.postgres.enable = true" to get a working DB).
I've gone full NixOS on my laptop and my gaming/homeserver desktop. I love it (even if there are parts I hate) and will never move to anything "less declarative". 100% no regrets.
However, I only recommend it with the caveat that the practical benefits are not worth the time invested and it's only worth it as a fun hobby. I think an immutable desktop like Silverblue/Bazzite is really the sweet spot.
Nix (non-OS) as a way to define dev environments though? Incredible, would recommend it in a heartbeat. Opening a project and knowing you are going to have the exact versions of all dependencies you need is so refreshing, or seeing that a public git repo has a `flake.nix` and being able to `nix run <url>` and download/build the project in one command is truly magic.
open to the select few who are able to ignore what the official documentation says and spend some on the (admittedly friendly) irc channel to learn how it REALLY works.
Haven't tried in a while and haven't checked the documentation now but back then the method for installing packages in the docs was commented on like "yeah you're not supposed to do that". Features were in a perpetual "experimental" but not really state.
Regarding "not supposed to do that": the docs mention you can install packages with commands like "nix-env -iA <package name>", using nix approximately the same way as apt or pacman. -- Trouble is, this is kindof a footgun. (e.g. it's a bad idea to run this command with sudo, even though you'd use sudo for equivalent commands). So, it's easier to just say "you're not supposed to do that".
i guess its for people who need to use things like node, npm, python etc. where dev environments and tools never seem to work out of the box and everyone uses different not-backward-compatible packages.
Knew you'd get comments asking why nix is important to the setup. I like it for things like this as well.
Shell scripting by default has terrible isolation. But the way Nix puts shell scripts together, you can be confident that a script's own PATH only contains what it needs to, which is a nice guarantee to have.
I don't see what nix is doing for you? There's vim, absolutely, coreutils (though I don't immediately see anything GNU-specific), and a tiny wrapper script that happens to be written in flake.nix but could trivially be factored out. I don't see anything that I wouldn't expect to run on, say, OpenBSD if you installed vim.
(That said, yes, it's a nice journaling system)
This is a pretty poor example for a few reasons, but the idea is that anyone get can a shell with the tool fully installed along with all its dependencies, with a single command:
nix shell 'git+https://tangled.sh/@oppi.li/journal'
It's massive overkill for a shell alias, but for a more complex project it can be very nice.
Sure; I'm typing this comment on a NixOS machine in a browser controlled from a flake I wrote myself - I get using nix and flakes in general. It's just that this particular case seems like such overkill that it actually seems like a weird tradeoff even if you're used to flakes.
One area that is especially a massive win is projects that cross multiple ecosystems. So like, C++ project with some Python bindings and a Typescript frontend? Setting up that dev environment is often a nightmare but Nix makes it trivial and highly reproducible.
Yea I don't see Nix doing much here particularly, but for me I typically would do something like this to make the system as consistent as possible over a long period of time without being actively maintained.
I guess this does ensure the key `journal` command works exactly the same because the dateutils binary will stay locked to the version in the `flake.lock`.
I would have assumed that nvim would also be locked because that's where I would expect more possible breaking changes with the existing special config.
With little tools/projects like these I could easily see months-years before it would get any active attention from me again (or simply I wouldn't be using it; so it doesn't matter).
I was somewhat expecting that the flake would include nvim bundled with the vimrc in the folder.
You could then just open nvim in the `nix develop` environment (or even use something like direnv to activate it when you cd in) and have a minimal journaling environment
Yeah, if it included ex. nvim plugins then it would make more sense to me. It's just this particular combination is for installing tools that I struggle to imagine aren't default-installed everywhere, and version-locking some of the most stable programs I've ever used (though I guess neovim might make breaking changes?). Honestly it strikes me as most useful as a 'hello world 2.0' flake demo.
Bundling a little script into your path like that is pretty cool, just overkill to use a flake + nix for _just_ that
Bring back blosxom: https://en.m.wikipedia.org/wiki/Blosxom
author seems to be the type to follow tech trends and use them to signal "coolness" - people like that use these absurd stacks because its niche, not for any actual benefit
If you want week numbers in the calendar, you can use `ncal -w` and they'll be the last row. Add a `-3` and you get:
There is also a `-b` flag to get it back in to the shape you'd expect from cal. I find the week column easier to read in that form:
Perhaps worth noting that ncal's -w is ISO-8601 compliant¹, which may surprise some people around new year as week numbers can reset in December or January.[Said as someone who aliases cal to "ncal -wb" mostly just to get the correct first day of the week for their locale.]
¹ https://en.wikipedia.org/wiki/ISO_week_date
So, I've been keeping a journal for 17 years, off and on. I don't know anyone else who does it my way, so here's my method.
I made a dedicated email account just for the journal. I personally chose gmail but if you distrust google you could use any other provider including self-hosted.
At the end of the day, or when I feel like it, I log in and email the account from itself with a message about whatever happened that day and whatever I'm thinking or feeling, and use the date for the subject line, like "August 12, 2025". I never, ever send emails to anything else from that account nor connect it to anything or use it for anything else. It is a total island.
The result is 17 years of easily-searchable journal, password-protected, backed-up, accessible from anywhere that has internet, can't be "lost" like a physical journal (yes I know I'm trusting google, but again, go self-host if you're worried about that), can't be "found" by someone looking through my things.
I can't even tell you how much value I've gotten out of it. You forget things you don't even know you forgot. So many little moments and days in life. You'll be shocked at the things you used to think and feel sometimes. You'll be shocked at whole magical days that you haven't thought of in years and years and likely would never have thought of again. It's a record of me changing over time and the phases I've gone through. I can't recommend it enough.
And it doesn't take much discipline, either. It's not something I "have" to do. I do it when I feel like it. There are years where I have only 25 entries, and others where I have 200. It depends how much I felt like writing. I find it spikes in years where I'm feeling very emotional, usually during bad times. But I've written down many great days too.
I love this take. I do something similar, in that my journal is completely isolated
For journal entries I record voice notes. I can do it quicker, and I can do it while I'm e.g. driving or walking. I feel that I capture a bit more emotion with it too. I've been doing this for about 20 years, but only in the last year have I been writing a python application to organize and transcribe the notes.
A message in a bottle, thrown into your own swimming pool every evening. I like it.
Do you do any edits for previous days? Seems like it would be difficult with email.
No. But editing a handwritten journal would hardly be any easier. It's a matter of what features you care about, I guess. I have never needed to edit past entries - that would be historical revisionism. It's not a feature I personally need for my journal. If I cared about that for some reason, I suppose I might use a different method.
If I realize I forgot something from yesterday, I just add it the next day.
WTF wish I thought of this 17 years ago
The best time to start journaling is 17 years ago, or today.
This is a great intro to in both Vim and general unix text processing.
When I first started reading I thought, why not use Vimwiki or org?
I’ve use vimwiki for years but I really like the approach taken here. It’s simple and robust.
Making use of Vim’s built in abbreviations and syntax highlighting is a neat touch.
here I am tangenting into wtf tangled.sh is, maybe that's the entire point of this submission.
I've seen it quite a bit on BlueSky with some devs I follow. It's a social git host built on-top of ATProto (The underlying tech of BlueSky): https://blog.tangled.sh/intro
Yeah, this is a good blog article and a great pitch for this service. There was a discussion yesterday about where to look for the next github...
I wish all my todo items had 2-3 words. This looks fine with the examples but I bet it’s not so clean with realistic data.
Nix always felt like an OS on the blockchain. It's fine if you value verifiability above everything, but becomes very burdensome if you find yourself tweaking your dev environment often. Still, I think it probably teaches good discipline.
I've found NixOS is fantastic for evolving my environment. Update `configuration.nix` and then `sudo nixos-rebuild switch`. Done.
What kind of "tweaks" are you doing? You could use `nix-shell` to try out a new environment. If you like it the environment, you can make it declarative by creating a `shell.nix` file.
If you want to go further, you might make consider making a flake, but I would recommend reading https://nix.dev/concepts/flakes.html first.
> Nix always felt like an OS on the blockchain. It's fine if you value verifiability above everything, but becomes very burdensome if you find yourself tweaking your dev environment often.
With Nix, "dev environment" can be scoped to be specific to a project. Where on a typical system, you might install a compiler & libraries, with Nix you can describe the development environment in isolation. (Dev Containers uses containers to similar effect).
I'd rephrase your comment as: NixOS is anti-practical. Rather than just changing a config (& restarting a service), you have to change a NixOS config, rebuild that, & switch to the updated config. -- I'd say NixOS (and Nix) support the mindset of "put in all the effort up front now, in order to save effort later".
If someone's written a nix-shell or devenv file for a project, then no further effort is required to get a working dev environment setup. (Devenv is notable for nicer DX over docker-compose for things like "services.postgres.enable = true" to get a working DB).
I've gone full NixOS on my laptop and my gaming/homeserver desktop. I love it (even if there are parts I hate) and will never move to anything "less declarative". 100% no regrets.
However, I only recommend it with the caveat that the practical benefits are not worth the time invested and it's only worth it as a fun hobby. I think an immutable desktop like Silverblue/Bazzite is really the sweet spot.
Nix (non-OS) as a way to define dev environments though? Incredible, would recommend it in a heartbeat. Opening a project and knowing you are going to have the exact versions of all dependencies you need is so refreshing, or seeing that a public git repo has a `flake.nix` and being able to `nix run <url>` and download/build the project in one command is truly magic.
I’ve made the compromise of using nix package manager on a normal Linux distro. Gives most of the features I care about, with basically no downsides.
Nix + Home Manager is a good combo if you don’t want to go the whole way. But yes, I would recommend starting with just Nix.
what is this nix religion I keep hearing about
Nix is a form of computing that's simultaneously 20 years in the past and 20 years in the future. I love it.
Honest answer though, it's a deterministic way of building up a computer/environment. Think pip/uv/packages.lock but for everything.
Deterministic but when the next gcc (or %insert_big_dependency%) update happens all your more obscure packages are broken for a couple of weeks.
Don't update immediately? Update immediately, but selectively? Nix offers many options here.
open to the select few who are able to ignore what the official documentation says and spend some on the (admittedly friendly) irc channel to learn how it REALLY works.
I've only dabbled, but what have you learned in the irc that isn't in the docs?
Haven't tried in a while and haven't checked the documentation now but back then the method for installing packages in the docs was commented on like "yeah you're not supposed to do that". Features were in a perpetual "experimental" but not really state.
Regarding "not supposed to do that": the docs mention you can install packages with commands like "nix-env -iA <package name>", using nix approximately the same way as apt or pacman. -- Trouble is, this is kindof a footgun. (e.g. it's a bad idea to run this command with sudo, even though you'd use sudo for equivalent commands). So, it's easier to just say "you're not supposed to do that".
I've done ok without irc, though now you mention it, I do miss me some irc.
i guess its for people who need to use things like node, npm, python etc. where dev environments and tools never seem to work out of the box and everyone uses different not-backward-compatible packages.
I've been doing similar in org-mode for several years at this point, though I have returned to pen and paper now.
gu