Jason Blevins, an academic, shares Emacs tools like Deft and Markdown Mode, along with notes on macOS, ssh and scientific computing.
Commenters recommend his Deft mode for fast incremental search over folders of notes, and HN links his ssh key vulnerability note.
> how do you manage information from digital content, e.g., notes from reading technical/research articles or blog posts?
If I could always remember the right keywords to search for the articles I had in mind, I'd just do that.
For online content, most of the time I'll wait for a later 'cache miss' before any bookmarks/notes.
(I'd either come across content when procrastinating on HN/etc., or from looking for it while doing a task. For the former, it's low-effort consumption. For the latter, it's hard to know if it's going to something I have difficulty finding later. IMO, it's not worth putting easy-to-Google things in; lots of stuff is easy to Google for).
For storing stuff, I prefer bookmarks to end up in pinboard, and notes to end up somewhere in org-mode. I've found the zetteldeft package to be useful for me. https://www.eliasstorms.net/zetteldeft/ (builds upon deft. https://jblevins.org/projects/deft/ ). - If in rare cases I find I want to remember some key idea or jargon without having to look it up, then I'll go to the effort of adding it to Anki.
> Edit: also, why should a package like ssh have so many random dependencies? They should make sure these kind of packages have the least of dependencies especially on these kind of packages that have one maintainer to reduce the security risks?
Using standard libraries for common stuff like compression, cryptography and whatnot is vastly more preferable over everyone shipping their own crypto, or worse, patches of crypto (see the Debian SSH key vulnerability of 2008 for an example [1]). For protocols it's in the end just as bad, it's a nightmare to keep different versions of the same program to be able to talk to each other, but now imagine a literal ton of programs who all have a wild mixture of statically shipped libraries, homegrown stuff that has barely been tested... no, just no. Not a world I'd like to live in.
[1] https://jblevins.org/log/ssh-vulnkey
The blog post mentions text expansion via Raycast, but macOS has had its own native text expansion for a long time now (I think maybe since 10.5? Would need to check) under System (Preferences|Settings) > Keyboard > Text Replacements, which comes with the added bonus of syncing to your other Macs and iDevices via iCloud. I've been using it for years and at least for my needs it works great.
Not mentioned are the text navigation shortcuts that have been built into macOS for a similarly long period of time. They work in any text field in nearly every app (with exception to a few oddball apps that are usually built with "game engine style" UI frameworks), and come in both control-based emacs style and Apple style flavors[0]. I use these constantly and they work exceptionally well for smaller keyboards (e.g. 60% or HHKB).
[0]: https://jblevins.org/log/kbd
Random numbers are used to generate your TLS certificate key or your SSH key. If one can predict how a TLS or SSH key was generated they could impersonate the key holder.
Here is an explanation of what was possible when a Debian packager mistakenly introduced a patch which reduced the SSL certificate keyspace in 2008: https://jblevins.org/log/ssh-vulnkey
The possibilities of keys which were generated by this random number generator was so small, that a brute-force attack on keys was feasible.
That being said, for years, random number generators have been using random signals coming to your computer (key strokes, network packets, ...) and feeding them into a sponge function. You don't need lava lamps or pendulums to generate random numbers, it's just for the press.
https://www.2uo.de/myths-about-urandom/
Keys, like passwords, can be leaked, so it's possible there are databases of leaked keys out in the world, because unlike PGP or SSL certs, ssh keys don't have a revocation mechanism built in. So they could just try all the known leaked keys - like they try known leaked or default passwords.
Then there was this: https://jblevins.org/log/ssh-vulnkey
(tl;dr - there was a bug in debian that caused ssh-keygen to only produce a very small number of keys rather than keys distributed across the whole keyspace). After that became public the bots were all about trying those keys for a few years after. To this day it's recommended to not used keys from that set.
Point being - the bots will try because it the tiny marginal cost is not high enough to stop the attempt.
> I'm pretty sure that the HN community likes to read thoughtful, thoroughly
> researched comments that are somewhat longer than one-liners.
Could not agree more and this is a great side effect of the time out. It
gives the commenter yet another reason to compose their comment in a real
editor. Personally I find the comment text box is too small to do a decent
job of assessing and editing my comment. A real editor also makes it easy
to format the above blockquote[^1] or to insert[^2] logical and consistent
footnotes.[^3]
[^1]: http://www.nicemice.net/par/
[^2]: http://jblevins.org/projects/markdown-mode/
[^3]: I just wish markdown-mode would renumber the footnotes if I go back and
insert a new footnote. As it is I have to pipe the output through pandoc