WebDAV support is nice to save money, but from a privacy perspective it’s a huge bummer that the sync servers get all your citation metadata. A better self-hosting story¹ is one path to resolving this. End-to-end encryption² similar to e.g. Firefox Sync is another. Zotero has a security overview³ that shows they clearly care about good practices, but it’s still bothersome to have to trust the server when many other applications have proven E2EE works great even for non-technical users⁴.
Unfortunately from the main Zotero dev’s responses, it seems clear that they have no incentive to implement either and probably never will (look, the same comment from 2½ years ago⁵) without some shift in circumstances (massive increase in funding, new regulatory requirements). Even if a community member implemented the entirety of either solution, dstillman can just (rightly, tbh) claim it will increase their maintenance burden when they are trying to support paying customers.
> I literally did not know info pages existed for the first 15 years I used GNU tools, and I've still never used one
A bit of irony: the link and screenshot in the OP are from the HTML version of an Info manual! In my book, that counts as using one :). HTML Info manuals are right up there with Stack Overflow for most queries about GNU tools. Most people who have searched the web for how to do something with Make, GCC, or tar have used an Info manual, unwittingly or otherwise. There are even two types of HTML export¹: one web page per node, good for sharing links, and everything on one page, good for lazy full-text search.
And while the TUI program is indeed pretty niche these days (probably partly due to the fact that it’s not installed by default in many environments), any Emacs user worth their salt is intimately familiar with Info-mode :D
I think it's not that you don't stumble, it's just that you avoid them concsiously or subconsciously.
For me it's almost 20 years now but the reflex is still "check the man quickly, then go to full html docs if necessary". It developed very early and then I never applied enough force to break it.
When thinking of my early Linux usage experience I guess the primary reasons why the reflex developed were the following:
1) In the beginning you barely understand what's happening and turn to docs very frequently, often feeling desperation by that point. Figuring out a complex interface in this state of mind feels extremely frustrating, because you're already in process of figuring out something else. Man/less interface is very limited but it's also comforting in its simplicity.
2) When you finally subside to the "info xxx should give you access to the complete manual" instruction it shows you the same man page but in a frustrating interface which feels like a cruel joke (you're desperate to solve something, remember). I didn't have doc packages installed and I had no way of knowing that at the time. I still think it's a horrible usability solution and if "info" showed the install instructions instead the story could have been different.
Issue #1 can be sidestepped by using the HTML docs, which are still info pages.
Issue #2, I think, is a packaging issue related to licensing and the peculiarities of Debian packaging rules. Normally, any time you install a package, you get the man pages and info pages.
Everything can be sidestepped, it's not the point. The point is for some users (a majority I suspect) info pages have the entry barrier too high. Not very high per se, but too high compared to what you normally expect from documentation which is no entry barrier at all. That happens due to an unfortunate combination of circumstances most of which have nothing to do with info pages format itself which is quite good.
Is it possible this is less of a reflection of the author's abilities and more of a reflection of your lack of imagination? Not everyone who reaches a destination follows the same path. Stack Overflow was launched just over 15 years ago, for what it's worth.
This. One uses less all the time for displaying text files anyway, so the commands are in muscle memory. Using info is always similar to accidentally launching vi and not knowing how to get around or even out of it.
(I’ve learned vim in the meantime, but just avoided info for the last 10+ years)
It seems to me we’re seeing something of a native GNOME application renaissance, both core and third-party, buoyed by GTK 4 and Flatpak (as well as the trend towards immutable base images). Rust seems to be part of this too—Loupe, Fractal, and Emmanuele Bassi’s recent GUADEC talk on oxidizing GTK¹ are examples. There are now three newer VTE-based terminal emulators targeting a native GNOME UX: Console (C), Black Box (Vala), and Prompt (C). Is there something about VTE or terminal emulators that makes Rust less appealing, or is this just a coincidence? I’m curious.
Prompt will probably be my next terminal emulator. That inspector looks interesting. Have you seen Ghostty’s recent demo²?
I might be biased, because I'm the author, but I think GNOME Builder making it dead simple to install an IDE from Flatpak, create a GTK 4 application template in numerous languages, and click run/debug/profile/valgrind and you're off to the races had a lot to do with it. It even installs the SDKs and extensions for you so your new-developer setup is install, clone this url, click run.
We built Flatpak and Builder in concert from the beginning to foster this exact outcome.
But as for language? I already hack on GTK/GDK/GSK internals in C, a mix of C++ and C to contribute to VTE, and Builder is 250k of C with another 200k in associated libraries. I'm just better at it and language bindings are never an issue.
If you configure annex.largefiles, git add should work with the annex. I start with something like
git annex config --set annex.largefiles 'largerthan=1kb and not (mimeencoding=us-ascii or mimeencoding=utf-8)'
> By default, git-annex add adds all files to the annex (except dotfiles), and git add adds files to git (unless they were added to the annex previously). When annex.largefiles is configured, both git annex add and git add will add matching large files to the annex, and the other files to git. —https://git-annex.branchable.com/git-annex/
Note that git add will add large files unlocked, though, since (as far as I understand) it’s assumed you’re still modifying them for safety:
> If you use git add to add a file to the annex, it will be added in unlocked form from the beginning. This allows workflows where a file starts out unlocked, is modified as necessary, and is locked once it reaches its final version. —https://git-annex.branchable.com/git-annex-unlock/
Ikiwiki’s definitely a bit weird, but I’ve been experimenting with git-annex recently and it worked fine every time I commented. Seems like it’s chugging along: https://git-annex.branchable.com/recentchanges/
When does it use hard links? As far as I remember it used symlinks unless you used something like annex.hardlink (described in the man page: https://git-annex.branchable.com/git-annex/)
Symlinks are just as problematic honestly, an app writing to it will change the object in the persistent "immutable" storage. The way the "check out" feature works is also weird, causing a change in the shared version history.
> Symlinks are just as problematic honestly, an app writing to it will change the object in the persistent "immutable" storage.
Well, anything stored by git-annex has read-only file permissions. Apps will follow the symlink, yes, but they will fail to write to the location if they try.
> The way the "check out" feature works is also weird, causing a change in the shared version history.
Unlocking a file changes it from a symlink to a git-annex pointer file from git’s perspective (git-annex accomplishes this via git’s smudge filter interface), but you don’t have to commit the unlock. You can unlock, modify locally, re-lock, and commit the new changed version in one go. It’s nice that you can commit the unlocking action itself if you want a file to be unlocked in all clones of the repository. You can choose whether to commit the unlock depending on if it fits your use case.
¹ https://www.imdb.com/list/ls000050037/?sort=release_date%2Ca...