Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Eshan Ramesh
    @esrh_gitlab

    Wondering whether jrnl has a plan to support unicode, since many of the terminals have supported utf8 input methods.

    As far as I can tell, it seems that jrnl already does support unicode. It should work with unicode journal names and journal text. Is there any way that jrnl can better support Chinese or other CJK? I'm willing to work to improve it.

    Karim Rahal
    @KarimPwnz
    O! Hello Eshan and Amy!
    Jonathan Wren
    @wren
    Hi, Eshan! Good to see you here. And thanks for bringing up the idea of a chat forum again. :)
    Welcome, Amy! What version of jrnl are you using? We started implementing unicode in v2.0, and made some further improvements in v2.3.
    That doesn't mean there aren't more we can make, though. :D
    eshrh
    @eshrh
    my orphan request to adopt the arch AUR jrnl-git package just got accepted :) i'm now maintaining it
    Jonathan Wren
    @wren
    oh, cool
    can you explain the difference between AUR and the other arch repo where jrnl is listed?
    I've never been super clear on that
    eshrh
    @eshrh

    yeah:

    the jrnl package is part of the official arch linux repository; it's hosted and maintained by one of the few trusted users (Felix Yan in our case) and can be installed directly. That's this one: https://archlinux.org/packages/community/any/jrnl/
    It will only ever use the latest stable version. It is also a redistributed binary, so users don't have to build everything.

    the jrnl-git package is the cutting edge version that uses the latest commit on the develop branch. because this can't really be trusted to always work, it can't be in the official repositories. It's instead in the arch-user-repository(AUR) which anyone can access at their own risk. Instead of hosting the actual binary, it just hosts a script(a PKGBUILD) that automatically downloads, test, builds, and installs the program. I now maintain this one: https://aur.archlinux.org/packages/jrnl-git/

    Jonathan Wren
    @wren
    Oh, cool. So, it's like a nightly version.
    Let us know if you need any help setting any of it up, and thanks for maintaining it! :)
    Karim Rahal
    @KarimPwnz
    Awesome, Eshan!
    eshrh
    @eshrh

    poetry run pyflakes . from the makefile is throwing this error:

    
      FileNotFoundError
    
      [Errno 2] No such file or directory
    
      at /usr/lib/python3.9/os.py:607 in _execvpe
           603│         path_list = map(fsencode, path_list)
           604for dir in path_list:
           605│         fullname = path.join(dir, file)
           606try:
        →  607│             exec_func(fullname, *argrest)
           608│         except (FileNotFoundError, NotADirectoryError) as e:
           609│             last_exc = e
           610│         except OSError as e:
           611│             last_exc = e

    any idea why this could happen?

    its pretty nondescriptive and i don't really know what happened
    Jonathan Wren
    @wren
    I think it's getting confused with a virtualenv?
    try changing it to poetry run pyflakes jrnl features and see if that helps
    Manuel Ebert
    @maebert

    Hey everyone, today is jrnlversary - the first commit to jrnl was written exactly 9 years ago:

    jrnl-org/jrnl@10a1d64

    It's safe to say that jrnl changed my life - it landed me my first job in tech for a startup in SF (I was in academia before), and continued to surprise me by how often amazing contributors showed up to fix things, improve things, and eventually steward the whole project into the form it's in now. So, a big thank you for all of your time and energy and here's to another 9 years of getting nerds to write. :)

    Karim Rahal
    @KarimPwnz
    Wohooo!!! Happy jrnlversary everyone! I haven’t had much time to contribute lately because of college, but it is a fun project and the maintainers are awesome. Glad to hear that you’re doing great, Manuel!
    Jonathan Wren
    @wren
    Happy jrnlversary! 🎉📓🥳
    Thanks again, @maebert, for everything! It's pretty safe to say that jrnl would not be where it is without you. ♥️
    Micah Jerome Ellison
    @micahellison
    Nine years, wow! Happy jrnlversary everyone. It's been a delight to work on this project with you all.
    Manuel Ebert
    @maebert
    Also funny to think that back then, org-mode was the behemoth that everybody talked about when they heard "command line note taking". Now jrnl is actually closer in age to org-mode (*2003 I believe) than to the present day :)
    Karim Rahal
    @KarimPwnz
    Hey all!
    I was thinking about the issue jrnl-org/jrnl#1107, and I think our future format should use a database, rather than the current journal/log data structure
    It would allow us to solve those collision issues, while perhaps giving a performance boost
    Although this would destroy the whole "one file" thing going for us
    Karim Rahal
    @KarimPwnz
    However, perhaps there is a data structure solution which allows us to maintain that ^
    Given that we're considering a new format, I think we should explore that pathway
    Micah Jerome Ellison
    @micahellison
    We have talked about supporting a database, yes! However, a big promise of the native jrnl format is that it's plain text and human readable
    I think, though, that we can find a compromise with support for storage format plugins. We'd still probably need unique identifiers in each entry for this to be extensible for a database, but that's something we've discussed also since a few years ago - jrnl-org/jrnl#519
    Jonathan Wren
    @wren
    To me, the promise of jrnl isn't necessarily that it's plain text or human readable, but that it's easily readable even after jrnl is no longer available.
    In practice, that often translates to plain text and human readable, but we do fudge that a little in some places
    Encryption comes to mind as the most prominent example (an encrypted jrnl file is neither plain text nor human readable), but we also do it in a few other places
    like how we insert an entry id (uuid?) for dayone journals when a user is editing an entry
    We also use yaml headers in a format (is there more than one?)
    So, plain text isn't a strict requirement in my mind, but any change to a storage format has to be evaluated through the lens of how it affects reading a journal if jrnl isn't available
    Jonathan Wren
    @wren
    The jump from flat files to a (presumably relational) database does seem like a jump in difficulty when viewed through that lens
    I'm not against it per se, but I would want to make sure we take a long, hard look at that before deciding to move away from flat files
    I lean towards the plugin-based solution Micah mentioned above to support a db format, but I'm open to more conversation
    Jonathan Wren
    @wren
    Does anyone have experience with bug bounty programs?
    This place is offering us a $250/month pot if we use their platform: https://huntr.dev/
    But I haven't use any of these place before
    I'd love to hear if anyone has experience or opinions about any of them
    @micahellison and I have been trying to think of ways to get some security-focused help, and a bug bounty program seems like maybe a good fit
    we could pay for it from donations, but $250/month seems pretty appealing (and is more than our current donations)
    eshrh
    @eshrh
    i'm not entirely sure, but i believe that hackerone seems to be the gold standard for bounty programs, especially their triage program
    Manuel Ebert
    @maebert
    I used hackerone at my previous company and it's a great way to get more eyeballs on our code! That said, typical bounties paid by companies are in the thousands of dollars, so it's worth looking into what $250/mo will get us.
    The other question is what constitutes a security vulnerability. Since we don't have any user data, the two that come up is encryption (vulnerability would be being able to read someone's journal if you have access to the encrypted files), or possibly but unlikely even remote code execution if you manage to tinker with an encrypted file.
    Micah Jerome Ellison
    @micahellison
    We ran into exactly that question with huntr.dev -- the one ticket we got from them was about an untrusted input vulnerability in the library we use to read the config file... which is not untrusted input