> I'm happy to see the move. Codeberg is probably a more stable/long-term solution than SourceHut as the founder is slightly unhinged
What's this about?
Maybe the incident:
Readit Newsdsissitka commented on Migrating the main Zig repository from GitHub to Codeberg ziglang.org/news/migratin... · Posted by u/todsacerdoti
dsissitka commented on PSF has withdrawn $1.5M proposal to US Government grant program pyfound.blogspot.com/2025... · Posted by u/lumpa
I'm rather baffled at the spike in HN folks missing obvious dates. You're not the first..
I wonder if they're mobile. Here the URL is truncated and over on openssf.org/blog they don't show the date unless you switch over to desktop view.
dsissitka commented on Be Careful with Obsidian phong.bearblog.dev/be-car... · Posted by u/allenleee
If you're a Linux user you might like Firejail for this.
firejail --appimage --net=none --private=~/path/to/jail ~/path/to/Obsidian.AppImage
dsissitka commented on Zed is now available on Windows zed.dev/blog/zed-for-wind... · Posted by u/meetpateltech
> you might be used to waiting 100 ms for a character you typed to appear.
The latest benchmark I could find is 2022 and it's nowhere as bad as you claim
https://github.com/microsoft/vscode/issues/161622#issuecomme...
I ran it on VS Code and kitty recently:
Chief Product Officer of Fastmail here. I see a lot of comments here from people that don't appear to have actually tried using the app, which is a little disappointing; don't knock it 'til you've tried it! Happy to answer any questions, but to answer the main ones that are popping up:
# Why Electron?
Because it lets us build an app that works well across all major platforms with the resources we have available. Building an email/contacts/calendar app is a huge undertaking. Doing it from scratch on each platform is just not feasible for us.
With Electron, we can maintain a single code base across all platforms so we can move faster, and keep feature parity everywhere. More than that though, we believe it lets us build a really great experience on each of these platforms, while offering a consistent UI for our customers across all their devices. Honestly, we can never out-native Apple because by definition whatever they do is "native", even if it sucks (Liquid Glass on the Mac is … not great UX). If that's your primary consideration, you will always be better with Apple's own Mail app, so it's pointless us trying to build something in that space. (And instead we work to also make Fastmail the best service to use Mail.app with — which we believe it is!)
# Why would you use this instead of the webmail?
If you prefer to keep Fastmail in your browser, great! You can do so. But we hear from many customers that they would rather not have their email mixed in with their tabs. With a separate app you can see it in the dock, Cmd-tab to it, make it your default email app system wide etc. It also lets us integrate with the system, like the Mac menu bar and native context menus.
# Why would you use this instead of an IMAP client?
If you've ever used the Fastmail web interface you probably already know the answer, but for everyone else…
1. It's a lot faster. Compared to Apple's Mail.app for example (which is a good IMAP client!):
- It resyncs way faster when you open the app, and uses a lot less data (JMAP is so much more efficient).
- Moving between messages is quicker. With Mail.app there's often a slight lag between clicking a message and it rendering. In Fastmail, it's usually instant.
- Add private memos to emails
- Mute conversations to ignore replies
- Pin important messages to the top of your inbox
- Schedule messages to send in the future (and not need your laptop to be online then for it to work)
- See related emails when you open your contacts.
- Add events straight into your calendar
- And much more (https://www.fastmail.com/features/).
# And finally…
This is just a choice. We hope this is something that some of our customers will love, but we're not backing away from our commitment to open standards and encourage everyone to find what works best for them.
I'll try to answer any other questions as I can.
I was just hoping for this a couple hours ago. :)
Any idea how far out the Linux version is?
dsissitka commented on Less is safer: Reducing the risk of supply chain attacks obsidian.md/blog/less-is-... · Posted by u/saeedesmaili
Going to preface this post by saying I use and love Obsidian, my entire life is effectively in an Obsidian vault, I pay for sync and as a user I'm extremely happy with it.
But as a developer this post is nonsense and extremely predictable [1]. We can expect countless others like it that explains how their use of these broken tools is different and just don't worry about it!
By their own linked Credits page there are 20 dependencies. Let's take one of those, electron, which itself has 3 dependencies according to npm. Picking one of those electron/get has 7 dependencies. One of those dependencies got, has 11 dependencies, one of those cacheable-request has 7 dependencies etc etc.
Now go back and pick another direct dependency of Obsidian and work your way down the dependency tree again. Does the Obsidian team review all these and who owns them? Do they trust each layer of the chain to pick up issues before it gets to them? Any one of these dependencies can be compromised. This is what it means to be. supply chain attack, you only have to quietly slip something into any one of these dependencies to have access to countless critical user data.
[1] https://drewdevault.com/2025/09/17/2025-09-17-An-impossible-...
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.
Some Typometer measurements on i3 here:
# Title Min Max Avg SD
1 xterm 397 3.1 4.0 3.5 0.2
2 Alacritty 0.15.1 3.6 4.8 4.2 0.2
3 xfce4-terminal 1.1.4 2.9 6.8 4.4 0.3
4 Ghostty 1.2.0 11.3 15.5 13.0 0.7
5 kitty 0.42.2 11.7 21.3 15.8 3.3
Bonus VS Code:
# Title Min Max Avg SD
1 VS Code 10.8 19.7 13.0 1.2Some Typometer measurements on i3 here:
# Title Min Max Avg SD
1 xterm 397 3.1 4.0 3.5 0.2
2 Alacritty 0.15.1 3.6 4.8 4.2 0.2
3 xfce4-terminal 1.1.4 2.9 6.8 4.4 0.3
4 Ghostty 1.2.0 11.3 15.5 13.0 0.7
5 kitty 0.42.2 11.7 21.3 15.8 3.3
dsissitka commented on Behind the scenes of Bun Install bun.com/blog/behind-the-s... · Posted by u/Bogdanp
I have been excited about bun for about a year, and I thought that 2025 is going to be its breakout year. It is really surprising to me that it is not more popular. I scanned top 100k repos on GitHub, and for new repos in 2025, npm is 35 times more popular and pnpm is 11 time more popular than bun [0][1]. The other up and coming javascript runtime, deno is not so popular either.
I wonder why that is? Is it because it is a runtime, and getting compatibility there is harder than just for a straight package manager?
Can someone who tried bun and didn't adopt it personally or at work chime in and say why?
[0] https://aleyan.com/blog/2025-task-runners-census/#javascript...
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:
https://github.com/oven-sh/bun/issues/16037
Last big issue I had with Deno was a memory leak:
https://github.com/denoland/deno/issues/24674
At this point I feel like the Node ecosystem will probably adopt the good parts of Bun/Deno before Bun/Deno really take off.
They both started this after the Witness came out, 10 years ago.
Since then, guess how many games Muratori has shipped? 0. (He cancelled his announced game.)
Guess how many Blow has shipped? 0 so far, but it sounds close now.
These engineers spent their time ragging on other developers for slinging bad code and doing things horribly, meanwhile those developers were shipping games and apps and all sorts of other stuff.
One, but it was something like three years late:
https://store.steampowered.com/app/499180/Braid_Anniversary_...