It's kinda funny that an article complaining about blurry rendering, is written using one of the most illegible fonts I've ever seen.
Readit NewsJelteF commented on Blurry rendering of games on Mac colincornaby.me/2025/08/y... · Posted by u/bangonkeyboard
Sample size of 16 is already hard enough to draw conclusions from. Sample size of 1 is even worse.
It's the most representative sample size if you're interested in your own performance though. I really don't care if other people are more productive with AI, if I'm the outlier that's not then I'd want to know.
JelteF commented on Denmark to raise retirement age to 70 telegraph.co.uk/world-new... · Posted by u/wslh
In Denmark, you also have to have a medical exam to maintain your drivers license after you turn 70, but they have no problem with carpenters running around on roofs until they're 74.
There's a huge difference between endangering other people vs endangering only yourself.
JelteF commented on Ruff: Python linter and code formatter written in Rust github.com/astral-sh/ruff... · Posted by u/modinfo
Folks said the same thing to me about grep 8.5 years ago when I released ripgrep.
Wait... Did you misunderstand this comment? Or are you saying grep caught up with ripgrep now?
There are a handful of git features which work significantly better with a clean history on main. If `git blame` points at a well crafted commit, it can help bring additional context to the line in question. In addition `git log -S<string>` can be used to find when code was introduced.
Both of these features aren't very useful when they point at a "wip" or similar commit message.
By all means push lots of little commits to your branch while you're figuring stuff out, but squash and rewrite history into logical commits (usually just one) before landing the change on main.
I learned about the --first-parent flag of git blame recently. It allows git blame to work well in repos that use merge commits.
JelteF commented on Started a guide to writing FUSE filesystems in Python gwolf.org/2024/10/started... · Posted by u/levlaz
Can you tell what's the usecase for creating FUSE for dokuwiki? Basically, dokuwiki is just a bunch of text files so wouldn't it be simpler and more efficient to e.g. mount them as NFS or share via Dropbox/Syncthing?
I was forced to use the dokuwiki, but I very much disliked editing stuff in the web interface. Having a filesystem interface to the wiki system allowed me to create and edit pages using vim , which I like to use for writing.
JelteF commented on Started a guide to writing FUSE filesystems in Python gwolf.org/2024/10/started... · Posted by u/levlaz
Quite some years ago I created a Python FUSE filesystem[1] to to interact with dokuwiki (a wiki system).
It's built on hde llfuse[2]. But that required implementing a bunch of low level APIs that were not really related to dokuwiki. So I created easyfuse[3][4] as a wrapper, which implemented the things that were unrelated the dokuwiki implementation. If you're interested it in building a FUSE system it might be worth looking at.
[1]: https://github.com/JelteF/dokuwikifuse [2]: https://pypi.org/project/llfuse/ [3]: https://pypi.org/project/easyfuse/ [4]: https://github.com/JelteF/easyfuse
Maybe i'm missing it, but I think this would be much more useful if it showed what the optimal way to navigate per-target was.
I actually think the wall clock time that is used here is a more useful metric here. Using as few keystrokes is not necessarily most "efficient" in time if you have to think longer about which ones to press.