Transmission 4.1.4 has been released today as the fourth maintenance update to the latest Transmission 4.1 series for this popular open-source BitTorrent client, a bugfix release that fixes various issues.

Coming almost four months after Transmission 4.1.3, which was a small update fixing a CORS bug that leaked the anti-CSRF nonce, a use-after-free bug in peer code, and a build error when compiling with fmt 12.2.0, the Transmission 4.1.4 release hardens the torrent-add RPC method against malformed requests.

Transmission 4.1.4 also fixes a regression introduced in Transmission 4.1 that could cause torrents with zero-byte files to be handled incorrectly, which could sometimes cause downloaded progress to be lost, and fixes a rare bug that could leave Transmission hung but running on it is closed.

This release also addresses a rare bug that could prevent downloading webseeds from finishing, a bug where setting TR_CURL_PROXY_SSL_NO_VERIFY broke origin server SSL verification, and a build failure that happened when building Transmission with -Wnull-dereference -Werror in GCC 12.15.

On top of that, Transmission 4.1.4 unifies launch and delegation between the Qt and GTK clients. According to the devs, if either is already running and then you or a browser’s MIME-type handler tries to start the other to add a new torrent, that new torrent will get handed off to the pre-existing session.

The GTK client has been updated to allow the torrent list to re-sort and re-apply its filter when the torrent’s top folder’s name changes, open the correct folder when a single-file torrent uses a directory structure when opening a torrent’s folder, and correctly show the app icon on some desktops.

The Qt Client received improvements to the UI code to use less CPU, the Web client received a fix for a display bug that sometimes listed torrent names as ‘Unknown’, while the macOS client was patched against a potential RCE vulnerability that requires local write access to the user’s preferences.

Last but not least, fixes a bug in transmission-remote that broke the --list-groups argument. Check out the release notes on the project’s GitHub page for more details, where you can download Transmission 4.1.4 as a source tarball if you fancy compiling it from sources.

[–] [S] 4 points 2 weeks ago

Do you know how hard it is to wrangle all the pixels together for an event‽ Pixel 4 bailed at the last minute and if 4 doesn't come then 5 doesn't either, 6 never RSVPd, 7 8 9 and now 10 won't show up and it just goes on and on from there

  • source
  • parent
  • context
  • [–] 5 points 2 weeks ago

    It's for a separate, but tangentially related, reason(s). Also each account used for this purpose has directions in the bio to an account listing for all other accounts used for this purpose.

    1. Promoting smaller instances, because of the volume of my posting it helps makes smaller instances more recognizable
    2. Making comms on fitting smaller instances (e.g. a programming comm id make on programming.dev)
    3. Mitigating against the imposter problem
    4. Better interconnecting smaller instances
  • source
  • parent
  • context
  • [–] 9 points 2 weeks ago (4 children)

    Context

    Why am I cross-posting .ml content?

    I cross-post from .ml to the nearest relevant non-.ml comm to reduce the influence of .ml comms and indirectly, the instance as a whole, to help vitalize non-.ml comms and make it an easier decision for other instance admins to defederate because one key reason I identified that admins don't want to defederate is because .ml still has some very large comms and some active niche comms.

    Megathread on the issue

    Some highlights from the link:

    Dessalines, head .ml admin, lead Lemmy dev actively spreading genocide denialism https://sh.itjust.works/post/61371958

    .ml admin, Nutomics continued transphobia https://lemmy.world/post/29222558 The original transphobic Comment from Nutomic: https://lemmy.world/post/18236068

    "If you don't support Russia then you just don't understand geopolitics" ~dessalines, .ml admin, dev https://lemmy.world/post/27352415

    "Don't worry guys, the Uyghur Genocide was REALLY just birth control! ~dessalines, .ml admin, dev https://lemmy.world/post/30580167

    "See! nobody died IN Tiananmen Square, just AROUND it, so it doesn't count!!" ~ Davel, .ml admin https://lemmy.world/post/30673342

    "NK is actually good and anything counter to that is Western propaganda!" ~dessalines, .ml admin, dev https://lemmy.world/post/31595035

    General negative sentiment to other instances who haven't "seen the way" yet ~davel, .ml admin https://lemmy.world/post/27426510

    And so so much documentation on clear heavy handed censorship and bias also on the link. So much I can't even put them all here because this comment would be really long.

    I believe the behavior of its admins (the main admins are Lemmy devs) does harm to the overall growth of the Lemmy-verse and maybe even the Thrediverse (since Lemmy kinda kicked off the Thrediverse) because of its association with the devs of Lemmy and their insistence to use .ml as their personal political platform to spread harmful propaganda

    On the outside, bringing up Lemmy frequently leads to comments like "Lemmy? Isn't that the place with a bunch of tankies?" Or "Tried Lemmy, but found it full of pro Russia crap so I left". The best way forward from that I see is to either widely defederate from .ml like the rest of the Triad, or pressure them to put a fair and unbiased as possible admin team.

  • source
  • parent
  • context
  • [–] [S] 1 point 1 month ago

    I don't automate anything really, just tapped into .mls rss feed to fire notifications to my phone for my .ml crossposting campaign. I think I just put in the wrong comm lol

    Why am I cross-posting .ml content?

    I cross-post from .ml to the nearest relevant non-.ml comm to reduce the influence of .ml comms and indirectly, the instance as a whole, to help vitalize non-.ml comms and make it an easier decision for other instance admins to defederate because one key reason I identified that admins don't want to defederate is because .ml still has some very large comms and some active niche comms.

    Megathread on the issue

    Some highlights from the link:

    Dessalines, head .ml admin, lead Lemmy dev actively spreading genocide denialism https://sh.itjust.works/post/61371958

    .ml admin, Nutomics continued transphobia https://lemmy.world/post/29222558 The original transphobic Comment from Nutomic: https://lemmy.world/post/18236068

    "If you don't support Russia then you just don't understand geopolitics" ~dessalines, .ml admin, dev https://lemmy.world/post/27352415

    "Don't worry guys, the Uyghur Genocide was REALLY just birth control! ~dessalines, .ml admin, dev https://lemmy.world/post/30580167

    "See! nobody died IN Tiananmen Square, just AROUND it, so it doesn't count!!" ~ Davel, .ml admin https://lemmy.world/post/30673342

    "NK is actually good and anything counter to that is Western propaganda!" ~dessalines, .ml admin, dev https://lemmy.world/post/31595035

    General negative sentiment to other instances who haven't "seen the way" yet ~davel, .ml admin https://lemmy.world/post/27426510

    And so so much documentation on clear heavy handed censorship and bias also on the link. So much I can't even put them all here because this comment would be really long.

    I believe the behavior of its admins (the main admins are Lemmy devs) does harm to the overall growth of the Lemmy-verse and maybe even the Thrediverse (since Lemmy kinda kicked off the Thrediverse) because of its association with the devs of Lemmy and their insistence to use .ml as their personal political platform to spread harmful propaganda

    On the outside, bringing up Lemmy frequently leads to comments like "Lemmy? Isn't that the place with a bunch of tankies?" Or "Tried Lemmy, but found it full of pro Russia crap so I left". The best way forward from that I see is to either widely defederate from .ml like the rest of the Triad, or pressure them to put a fair and unbiased as possible admin team.

  • source
  • parent
  • context
  • view more: next ›