Indeed. Which carries through to this: If you're telling your users that you use {lower_level_crypto}, either you really mean "we're using GPG", and you should say that, or you rolled your own and you're violating the aforementioned suggestion.
In my defence, I wrote that before Snowden (the events, not the person). In fact I absolutely agree that encryption is probably ineffective if you're trying to hide stuff from a government.
However the main use for encryption is to store your journal on an insecure medium such as Dropbox, and I believe encryption is still the best way to keep your data from companies you don't trust.
(Then again, after Condoleezza Rice got on the board of Dropbox, I'm not so sure anymore.)
I keep a coding journal of all those unsettled questions and thoughts that pop in my mind. The questions I ask myself, the things I could improve,... It turns out to be highly valuable in my projects and I recommend anyone to try it.
def make_key(self, password):
"""Creates an encryption key from the default password or prompts for a new password."""
self.key = hashlib.sha256(password.encode("utf-8")).digest()
Nice util. Just a suggestion for the encryption: You should consider using a password-based key derivation function (PBKDF) rather than just hashing the key once with SHA256. This could help deter brute-force attacks particularly if the chosen hashing function is computationally intensive; e.g. scrypt
I almost really like this tool. It's close to being seamless and Unixy, offering a pretty small command-line-option-language that expresses a bunch of journal-related commands. I like that idea, a lot. But the recipes dive right into piping text through wc and grep, so I wonder: what exactly does this offer over some bash functions and raw textfiles? I've already got cat, grep, find, tail, xargs et al.
More nitpicking: the * escaping bothers me. That's a core feature, using the * to mark things, but you have to avoid letting bash expand it. Are there any better characters? Does 'single quoting' help anything?
The fuzzy date parsing looks great. (: I also think the no-dash (new entry) vs dash (filters..) vs double-dash (action) convention is fairly neat as far as calling conventions go. Tagging things with @ seems like a useful convention, too, even if I end up using notepad.
Thanks :) In fact, jrnl started as exactly that: some bash functions over a text file. But then I wanted encryption. And I wanted fuzzy date parsing. There we go...
I agree that the * is not perfect. Turns out there aren't so many characters that are accessible on most keyboards (also non-US layouts) that are NOT already special characters on most shells. Suggestions welcome!
It's more about organization and presentation than privacy. For example, it can generate a tex file that converts your entries into a nicely formatted pdf file.
I also like the automated self-analytics Stephen Wolfram uses:
I've been tracking various git actions (commits and branch creates and checkouts) in a file via git hooks for the past year or so and it's been super valuable to go back and look at, especially to remind myself what I was doing yesterday for standup meetings.
This is far and away a better solution, since I can have `jrnl` auto-tag those things and filter them in/out when I want to look at regular journal entries.
Yeah, this is great for commits, but I've found that I personally commit in sort of random patterns, and I'll stash rather than commit when I'm temporarily switching tasks that need a branch change.
That's probably a really bad habit, but journaling branch changes helps me quite a bit.
Consistently journaling has been my most valuable habit over the past 5 years.
It's the only way to relive thoughts I'll never have again because I become jaded. It's also a great way to grasp just how much of everything I forget. I wonder if I'd even have any personal stories to tell from the time I studied in Prague if I hadn't written so much of it down while enamored by it all.
I'm also in the habit of journaling. But for me it is much easier to write than to read my journal. I write almost everyday and some days I write several entries in the journal. Now I'd like to have a good method to retrieve the knowledge buried in the journal. For some entries I set alarms (after one year, three months, ...) but the rest is just buried. How do you effectively retrieve and review old entries? Do you have a consistent method?
Any sort of system I've tried to come up with for reading and writing only ensured that I didn't do either.
I rarely read my stuff. And much of it I don't really want to read. — Once I have the power of hindsight, reminding myself of squandered opportunities and silly apprehensions I once had (in great cathartic unending detail, no less) can be a hard pill to swallow.
But those couple days each year I spend a moment flipping back to a random page in my life — however so infrequently — are rich with perspective. There seems to be a lot of wisdom in that delta between then and now. Like reliving how terrified I was of some impending event in my past and now, years later, really being able to internalize the reality of "That wasn't so bad, was it? You could've just relaxed that whole time. Next time, just relax."
I don't think it's essential to revisit your writings regularly. I reckon most of the value in writing is the self-reflection necessary to serialize your mind to paper in the first place. It forces you to confront yourself when it's far easier to perpetually avoid yourself up until the very end. I think when you're analyzing yourself from the outside, you have no choice but to grow in some way.
As long as you're writing at all, I think you're doing fine.
Get the computer to read old entries to you while you're doing the dishes (or stretching). The Mac OS computer voices are not bad at all. You can set the speed to medium-fast and it becomes quite good.
I practically don't read any text anymore---it's so much easier when the computer reads to me... also easier on the eyes.
I use vimwiki diary mode, and a cronjob that pops up a vim window (with pre-populated timestamp) every 30 minutes.
Been doing that for over 18 months now.
Looks great! though I'd have loved it even more if there were binaries available. I just like having all my favorite applications in one portable folder. I'm guessing using something like py2exe to create one won't be hard.
Also, what are the chances that the jrnl[encrypted] package will work on Windows? (without using Cygwin?)
Hi, creator of the package here. If you install the pycrypto package first, jrnl should work fine on Windows, too. It only needs a gcc compiler to build from source [1], but there are even pre-compiled binaries [2] (I don't have any experience with them though - please let me know if it works) :)
I think py2exe could work well, too! Otherwise you could create a virtual environment with virtualenv and install all the dependencies into one folder.
I have too much on my hands right now, but will definitely try to create an executable, but don't you think it'd make sense to provide binary releases? I mean, there might be others like me.
I'll also try the encrypted version. Will let you know if it works (or it doesn't) :)
Just tried installing the encrypted version (after installing pycrypto binaries.) It didn't work as these binaries do not include GMP/MPIR _fastmath, and I got lot of errors related to the them during install.
Would rewriting the application just to be able to provide releases make sense? What other benefits can one get when writing command line applications in Go? (as compared to python)
I am asking this because I myself plan to write a small command line tool in Python. I have never wrote (or read) a line of Go though, so would like to know.
Creating it in Go would relieve the user of installing and/or compiling any other libs to run the application in Python, a set of static binaries which could be compiled to run on FreeBSD,OSX,Linux,Windows without much effort.
This sounds great. I use Day One for my personal diary and org-mode for work stuff. This setup was quite good but now it is much better because, if it works as promised, Jrnl will allow me to add personal entries in Day One from the linux computer I use at work. Thanks! :-)
I just tested this with zimwiki, works perfectly, as it's all plain text files.
http://zim-wiki.org/
I didn't try it with encryption as zim wouldn't understand it.
Fantastic! I made a quick and dirty BASH solution two years ago and I've been meaning to rewrite it in python ever since. It's uncanny how similar this design is to what I was planning, though.
If the author sees these, I'll also note that I went to a different tab for a while and when I came back, the homepage animation was going at warp speed to catch up to reality.
I use it to organize and log my work. I also use it to write documents and to publish my own personal website (http://pere.quintanasegui.com).
Basically, I have a file, which is a tree. Each node is an "area" (work, personal), and each area is divided in subareas (projects, internal meetings, etc.) and each subarea is roughly divided in projects, which are divided in subprojects and tasks (more or less). This sounds complicated but it isn't. It allows me to find the exact place where to fill something. Tasks have an status, a deadline, a scheduled time and tags. Then, everyday, in the agenda, I find the tasks of the day and upcoming deadlines. I use tags to filter the tasks. Finally, while doing the tasks, I log the process of completing it. Tasks should be simple actionable items. If they are complex, I divide them in simpler parts. Some tags are recurring and sometimes I also add reminders to certain tasks or journal entries, to remember something that happened. Everything is versioned under git. Sometimes, I delete a subtree by error and git has allowed me to recover from these errors.
Org-mode is an extension to my brain. It is very useful. Unfortunately, I had some problems with MobileOrg on the iPad. That would make it even more useful when traveling.
Encryption currently only works for plain text based journals; DayOne journals can't be encrypted (since DayOne can't deal with encrypted journals either). I hope they'll change that though, as they promised loooong time ago.
You mean when DayOne has a sync conflict? That depends on the method of syncing, I guess, which is different between DropBox and iCloud as far as I know. If I remember correctly, in iCloud the conflicting file will be ignored, while in Dropbox you'll have two entries. None of these is perfect I admit. If that's important to you, I'll look into it and we can come up with a well-defined behaviour for that, just open an issue on https://github.com/maebert/jrnl/issues !
Can we please, as an industry, agree to stop using bogus terminology like this?
"Even the NSA won't be able to read your dirty secrets"
And can we stop using ~"Our encryption beats the NSA" as a selling point, given that:
1. It doesn't take into consideration the various side-channel attacks the NSA would actually use
2. It's unlikely to be true even discounting side-channel attacks
3. It's a scare tactic at best, akin selling boats that are rated "kraken-proof".