He apparently pretended to not have written it despite its DNS pointing to his servers, and Certificate Transparency logs and Internet Archive all attributing the page to his domain. Compare the top comment thread in the first link above to his reply there:
Which part of the second link? Some of it is very accurately sourced, he 100% operates a loli bot which targetted subreddits banned by reddit for illegal content. Theres no walking around that. Near the end they also point out that Drew changes his TOS for SourceHut to align with banning projects he disagrees with, which makes GitHub look like paradise.
> the incident is that he wrote a document detailing repeated bad behaviour from a well known community figure? And this is a bad thing?
He collected all Stallman statements about Epstein and related subjects (this is perfectly ok) and then wrote his own summaries which completely misrepresent the things which were actually said. So what happened was that a lot of people just skimmed the summaries and concluded that Stallman molests children, or says that it's ok to do so etc etc.
If fact I have taken to link the Stallman report and add "don't read the summaries, read only the things that Stallman actually said". This only works if I believe the person is in good faith, of course. I would suggest the same to you.
Kinda horrible to see that the 4chan bigots use the same strategy to try to discredit drew devault, and implying things of ownership through their own created fake accounts and smearing campaigns. Pretty much all allegations on that page are circumstantial evidence, especially the bot ownership parts that sircmpwn even took down while citing those bigots using it to scrape child porn.
And then the dude of dmpwn posting things on image boards with the tag dmpwn, and forgetting to remove that from screenshots? lol, really?
Having experienced the same kind of doxxing attempts by 4chan bigots, /pol/ and kiwifarms, I think I am qualified to comment on how they operate.
Maybe someone needs to summon the Antichrist a second time to thin out the herd, huh?
Thanks for mentioning it! Makes me glad to live a life out of the spotlight and to be generally ignorant of stuff like this going on. Would not want to be targeted like that :/
I hate that this is now a thing you can ask unsarcastically.
Just use the tool you like the best man, screw what other people think. Yes, there's people who will go "you're bad because your use a tool that's made by a guy who said something wrong about Stallman" (or whatever he did exactly again). These people are not worth your attention.
My bad, I shouldn't have said tainted. Trustworthy is what I had in mind.
I moved my private repos to sr.ht ages ago because it was the open source, free software, ethical, longevitable approach. And stepping away from the mega corporations and everything going on with those.
--private=~/path/to/jail limits access to your home directory to ~/path/to/jail and when you don't want Obsidian to have internet access you can take it away with --net=none.
Note that if you already have an Obsidian vault, suddenly jailing it might break things. Obsidian stores a bunch of state in ~/.config/obsidian which will no longer be valid. And amusingly/frustratingly, the GTK file picker doesn't take the jail into account and seems to produce invalid paths.
And because --private mounts some bits as temporary filesystems, you might end up losing state. Try before you buy.
It provides a sandbox, an API to access stuff outside of it (portals), and standard tools to customize what your software has access to (Flatseal, KDE app settings). It's based on the same technology as Docker containers, but for user-space GUI apps.
AppImage is a binary distribution format that does none of that stuff, so you need external tools, like firejail, to limit what the application has access to.
Coincidentally I did that yesterday. Mermaid pulls in 137 dependencies. I love Obsidian and the Obsidian folks seem like good people but I did end up sandboxing it.
Typometer is a tool to measure and analyze the visual latency of text editors.
Editor latency is the delay between an input event and a corresponding screen update — in particular, the delay between keystroke and character appearance. While there are many kinds of delays (caret movement, line editing, etc.), typing latency is a major predictor of editor usability.
Check the article typing with pleasure to learn more about editor latency and its effects on typing performance.
> While there are many excellent terminal emulators available, they all force you to choose between speed, features, or native UIs. Ghostty provides all three. In all categories, I am not trying to claim that Ghostty is the best (i.e. the fastest, most feature-rich, or most native). But Ghostty is competitive in all three categories and Ghostty doesn't make you choose between them.
I really want to like Bun and Deno. I've tried using both several times and so far I've never made it more than a few thousand lines of code before hitting a deal breaker.
Last big issue I had with Bun was streams closing early:
The bun team uses Discord to kick off the Claude bot, so someone probably saw the comment and told it to do it. that edit doesn't look particularly good though
Another thing is that they appear to have some spam scanning on outbound emails and when they detect something suspicious they simply drop the email silently, and nobody will ever know about it.
Oh, thank you.
I recently considered moving from posteo.de to mailbox.org, but I think I won't anymore regarding such an issue took so long to even be considered as a problem and as I understand is still not solved.
Unfortunately this is common in many smtp servers and is configuration dependent: After you authenticate as usera@example.com you can send emails as userb@example.com.
### July 22nd, 2025, Modernization of contributions
The project is modernizing its contribution methods and switching to a software
forge.
We have setup a platform on [code.ffmpeg.org](https://code.ffmpeg.org/). The new
process features continuous integration on all commits and merge requests,
labelling for categorization, conflict resolution, and logging in via OpenID or
Github.
The main repository will become
[code.ffmpeg.org/FFmpeg/FFmpeg](https://code.ffmpeg.org/FFmpeg/FFmpeg), with all
others being mirrored to it. Users are encouraged to begin using it, effective
now.
Mailing lists have supported our development for nearly 25 years, but as more
and more contributors started to become involved, the ratio of merged patches to
total mails begun falling. Mailing lists became a source of friction, with
discussions frequently stalling and uncategorized noise drowning out patches by
bumping them down in inboxes.
Although [patchwork.ffmpeg.org](https://patch.ffmpeg.org/) was set up to track
submissions, it was less than reliable, with many patches and mails slipping
though. Since its activation exactly 9 years ago, it recorded 54,476 patches,
with 53,650 patches having the state of not archived. In comparison, the mailing
list has had a total of 150,736 emails during the same time period.
Additionally, new users have frequently encountered difficulties with mailing
list development. From finding out the correct SMTP login details, configuring
git send-email, new email security mechanisms interfering with mailing list
operations, and finally not having a comfortable workflow to review patches.
After years of discussions, and a vote, we officially announce the new platform,
[code.ffmpeg.org](https://code.ffmpeg.org/), running
[Forgejo](https://forgejo.org/). Documentation will be updated to reflect the
change.
Mailing lists will continue to be monitored, and used for project discussions
and other topics better discussed elsewhere, but traffic and noise should become
significantly reduced over time.
Bugs/issues will be accepted on [code.ffmpeg.org](https://code.ffmpeg.org/),
alongside with [trac.ffmpeg.org](https://trac.ffmpeg.org/) for the time being.
We are also hoping that this will significantly reduce the amount of unmerged
patches. If you submitted a patch which received no replies or conclusion, we
apologize, and you are encouraged to resubmit it on the new platform.
For those with a power-user email setup geared towards mailing lists and patch handling, modern web-based platforms are a substantial usability regression.
Some times HN comments are a time machine that reveal people stuck in the past who hate anything modern.
A couple weeks back someone was arguing that websites these days are too slow. So slow that it took them minutes of waiting time to order something online. Then they revealed that they were using a computer that was nearly two decades old and didn’t even have enough RAM to meet the requirements of a modern OS and browser. “But it should work!” was their refrain.
https://news.ycombinator.com/item?id=41837782
https://dmpwn.info/