HN user

dsissitka

818 karma
Posts2
Comments267
View on HN

Proton apps are very janky in comparison. For example:

  You open Proton Mail.

  You'd like to read the second email in your inbox so you hit J a couple times.

  Nothing happens.

  J/K don't work unless an email is already selected so you use your mouse instead.

  You hit T to move the email to the trash.

  You'd like to read the next email so you hit J.

  Nothing happens.

  Hitting T didn't leave you with a selected email so J/K don't work.
There are a lot of issues like this.

I was curious how much work this would be. Here are the top five from cloc:

    -------------------------------------------------
    Language      files    blank    comment      code
    -------------------------------------------------
    Zig            1298    79693      60320    571814
    TypeScript     2600    67434     115281    471122
    JavaScript     4344    36947      37653    290873
    C++             583    27129      19117    215531
    C               111    21577      83914    199576

D'oh, it wasn't the doc site. I was lazy:

  $ bun build --help | grep Implies
      --compile                             Generate a standalone Bun executable containing your bundled code. Implies --production
  $
I actually did double check it though because it used to be wrong. For good measure:
  $ grep bun build
  bun build --bytecode --compile --outfile bun-darwin-arm64         --production --target bun-darwin-arm64         app.ts
  bun build --bytecode --compile --outfile bun-darwin-x64           --production --target bun-darwin-x64           app.ts
  bun build --bytecode --compile --outfile bun-darwin-x64-baseline  --production --target bun-darwin-x64-baseline  app.ts
  bun build --bytecode --compile --outfile bun-linux-arm64          --production --target bun-linux-arm64          app.ts
  bun build --bytecode --compile --outfile bun-linux-arm64-musl     --production --target bun-linux-arm64-musl     app.ts
  bun build --bytecode --compile --outfile bun-linux-x64            --production --target bun-linux-x64            app.ts
  bun build --bytecode --compile --outfile bun-linux-x64-baseline   --production --target bun-linux-x64-baseline   app.ts
  bun build --bytecode --compile --outfile bun-linux-x64-modern     --production --target bun-linux-x64-modern     app.ts
  bun build --bytecode --compile --outfile bun-linux-x64-musl       --production --target bun-linux-x64-musl       app.ts
  bun build --bytecode --compile --outfile bun-windows-arm64        --production --target bun-windows-arm64        app.ts
  bun build --bytecode --compile --outfile bun-windows-x64          --production --target bun-windows-x64          app.ts
  bun build --bytecode --compile --outfile bun-windows-x64-baseline --production --target bun-windows-x64-baseline app.ts
  bun build --bytecode --compile --outfile bun-windows-x64-modern   --production --target bun-windows-x64-modern   app.ts
  $ ls -1hs bun*
   59M bun-darwin-arm64
   64M bun-darwin-x64
   64M bun-darwin-x64-baseline
   95M bun-linux-arm64
   89M bun-linux-arm64-musl
   95M bun-linux-x64
   94M bun-linux-x64-baseline
   95M bun-linux-x64-modern
   90M bun-linux-x64-musl
  107M bun-windows-arm64.exe
  110M bun-windows-x64-baseline.exe
  111M bun-windows-x64.exe
  111M bun-windows-x64-modern.exe
  $

I was curious:

  $ cat app.ts
  console.log("Hello, world!");
  $ cat build
  #!/usr/bin/env bash
  
  bun build --compile --outfile bun-darwin-arm64         --target bun-darwin-arm64         app.ts
  bun build --compile --outfile bun-darwin-x64           --target bun-darwin-x64           app.ts
  bun build --compile --outfile bun-darwin-x64-baseline  --target bun-darwin-x64-baseline  app.ts
  bun build --compile --outfile bun-linux-arm64          --target bun-linux-arm64          app.ts
  bun build --compile --outfile bun-linux-arm64-musl     --target bun-linux-arm64-musl     app.ts
  bun build --compile --outfile bun-linux-x64            --target bun-linux-x64            app.ts
  bun build --compile --outfile bun-linux-x64-baseline   --target bun-linux-x64-baseline   app.ts
  bun build --compile --outfile bun-linux-x64-modern     --target bun-linux-x64-modern     app.ts
  bun build --compile --outfile bun-linux-x64-musl       --target bun-linux-x64-musl       app.ts
  bun build --compile --outfile bun-windows-arm64        --target bun-windows-arm64        app.ts
  bun build --compile --outfile bun-windows-x64          --target bun-windows-x64          app.ts
  bun build --compile --outfile bun-windows-x64-baseline --target bun-windows-x64-baseline app.ts
  bun build --compile --outfile bun-windows-x64-modern   --target bun-windows-x64-modern   app.ts
  
  deno compile --output deno-x86_64-pc-windows-msvc    --target x86_64-pc-windows-msvc    app.ts
  deno compile --output deno-x86_64-apple-darwin       --target x86_64-apple-darwin       app.ts
  deno compile --output deno-aarch64-apple-darwin      --target aarch64-apple-darwin      app.ts
  deno compile --output deno-x86_64-unknown-linux-gnu  --target x86_64-unknown-linux-gnu  app.ts
  deno compile --output deno-aarch64-unknown-linux-gnu --target aarch64-unknown-linux-gnu app.ts
  $ ls -1hs
  total 1.6G
  4.0K app.ts
  4.0K build
   59M bun-darwin-arm64
   64M bun-darwin-x64
   64M bun-darwin-x64-baseline
   95M bun-linux-arm64
   89M bun-linux-arm64-musl
   95M bun-linux-x64
   94M bun-linux-x64-baseline
   95M bun-linux-x64-modern
   90M bun-linux-x64-musl
  107M bun-windows-arm64.exe
  110M bun-windows-x64-baseline.exe
  111M bun-windows-x64.exe
  111M bun-windows-x64-modern.exe
   77M deno-aarch64-apple-darwin
   87M deno-aarch64-unknown-linux-gnu
   84M deno-x86_64-apple-darwin
   92M deno-x86_64-pc-windows-msvc.exe
   93M deno-x86_64-unknown-linux-gnu
  $
Maybe I'm missing some flags? Bun's docs say --compile implies --production. I don't see anything in Deno's docs.

If you're a Linux user you might like Firejail for this.

  firejail --appimage --net=none --private=~/path/to/jail ~/path/to/Obsidian.AppImage
--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.
Ghostty 1.2.0 10 months ago

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
https://imgur.com/a/RobYTWY

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.

It sounds like they're still testing but there's this from https://ffmpeg.org/pipermail/ffmpeg-devel/2025-July/346938.h...:

  ### 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.

But now it's on a timeline you can scroll through in reverse chronological order, with each breach summarising what happened.

Maybe I'm reading it wrong but it looks like it might be a little off. I get:

- October 2013

- June 2008

- ...a bunch more...

- November 2021

- December 2020

You might like Typometer. I believe it was created by a JetBrains developer to improve input latency in IDEA.

Typometer works by generating OS input events and using screen capture to measure the delay between a keystroke and a corresponding screen update. Hence, the measurement encompasses all the constituents of processing latency (i. e. OS queue, VM, editor, GPU pipeline, buffering, window manager and possible V-Sync).

https://pavelfatin.com/typing-with-pleasure/

I don't know about VS Code's dev containers extension but the SSH extension's README says:

Using Remote-SSH opens a connection between your local machine and the remote. Only use Remote-SSH to connect to secure remote machines that you trust and that are owned by a party whom you trust. A compromised remote could use the VS Code Remote connection to execute code on your local machine.

https://marketplace.visualstudio.com/items?itemName=ms-vscod...

If you're worried about extensions there's also:

When a user installs an extension, VS Code automatically installs it to the correct location based on its kind. If an extension can run as either kind, VS Code will attempt to choose the optimal one for the situation;

https://code.visualstudio.com/api/advanced-topics/remote-ext...

That being said, $10/mo is also expensive.

Back in the beta they planned on launching with a $20-$30/month unlimited plan and they didn't think they'd be able to bring the price down. That was a little too expensive for me so I moved on. I like what they're doing and I'd pay $10/month but I just don't have a use for it anymore.