Whole-known-network
<p>i managed to get it to over 420 KB/s (that's 3 Mbps of effective bandwidth--useful data transferred, the JTAG is running much faster--without using fast data channels!) by committing a few crimes in the implementation</p><p>at this point the debug probe is so fast it's outrunning the serial flash by a silly margin, and i need better handshaking to not read garbage from slow peripherals</p>
<p>EA rebrand and refresh their anti-cheat into EA Javelin Anticheat, still blocks Linux / Steam Deck <a href="https://www.gamingonlinux.com/2025/04/ea-rebrand-and-refresh-their-anti-cheat-into-ea-javelin-anticheat-still-blocks-linux-steam-deck/" target="_blank" rel="nofollow noopener" translate="no"><span class="invisible">https://www.</span><span class="ellipsis">gamingonlinux.com/2025/04/ea-r</span><span class="invisible">ebrand-and-refresh-their-anti-cheat-into-ea-javelin-anticheat-still-blocks-linux-steam-deck/</span></a></p><p><a href="https://mastodon.social/tags/EA" class="mention hashtag" rel="tag">#<span>EA</span></a> <a href="https://mastodon.social/tags/AntiCheat" class="mention hashtag" rel="tag">#<span>AntiCheat</span></a> <a href="https://mastodon.social/tags/Gaming" class="mention hashtag" rel="tag">#<span>Gaming</span></a> <a href="https://mastodon.social/tags/Linux" class="mention hashtag" rel="tag">#<span>Linux</span></a> <a href="https://mastodon.social/tags/SteamDeck" class="mention hashtag" rel="tag">#<span>SteamDeck</span></a> <a href="https://mastodon.social/tags/SteamOS" class="mention hashtag" rel="tag">#<span>SteamOS</span></a></p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@mhoye" class="u-url mention">@<span>mhoye</span></a></span> That article is giving me flashbacks to my whole denial of tenure. I jokingly tell people that I chose the "perish" option. However, it's no joke. I never wanted to play that dumb game--and frankly viewed ACM/IEEE as hostile. </p><p>Yeah, a "yearly career exam" coupled with that awesomely memorable experience of fighting the thesis editor over the Chicago manual of style. Sign me up! Not.</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@patricoferris" class="u-url mention">@<span>patricoferris</span></a></span> The objective is to summarise what we have found and propose a partial path to improve our ecosystem. We still have significant use for Cstruct. We could take a radical approach and directly change Cstruct to Bstruct, but Cstruct's revdep tells me that this would be a bad idea :tinking:</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@patricoferris" class="u-url mention">@<span>patricoferris</span></a></span> For the C code, it remains fairly similar to what you can get with Cstruct or Bigstringaf but improved with what OCaml can now do.</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@patricoferris" class="u-url mention">@<span>patricoferris</span></a></span> Yes, I also looked at your work 🙂 . My point was mainly to have a Slice type but with an abstract `buf` (which could be a bigstring or bytes: `'a Slice.t`). Then, we needed to propose an API like Cstruct but for `Bstr.t Slice.t` and `bytes Slice.t`, so I created a poor man's functor to avoid code duplication. In terms of performance, this is the best solution.</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> Optimizing these debug transports is fun. Looking at this comment in my SWD tooling from ages ago (about how many SWD ops fit in command buffer to the probe firmware)...</p><p>// 10 txns overhead per 128 read txns - 126KB/s on 72MHz STM32F<br />// 8 txns overhead per 128 write txns - 99KB/s on 72MHz STM32F</p>
<p>EA cancels multiple projects from Apex and Titanfall developer Respawn with more layoffs <a href="https://www.gamingonlinux.com/2025/04/ea-cancels-multiple-projects-from-apex-and-titanfall-developer-respawn-with-more-layoffs/" target="_blank" rel="nofollow noopener" translate="no"><span class="invisible">https://www.</span><span class="ellipsis">gamingonlinux.com/2025/04/ea-c</span><span class="invisible">ancels-multiple-projects-from-apex-and-titanfall-developer-respawn-with-more-layoffs/</span></a></p><p><a href="https://mastodon.social/tags/EA" class="mention hashtag" rel="tag">#<span>EA</span></a> <a href="https://mastodon.social/tags/Respawn" class="mention hashtag" rel="tag">#<span>Respawn</span></a> <a href="https://mastodon.social/tags/Titanfall" class="mention hashtag" rel="tag">#<span>Titanfall</span></a> <a href="https://mastodon.social/tags/ApexLegends" class="mention hashtag" rel="tag">#<span>ApexLegends</span></a></p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@dinosaure" class="u-url mention">@<span>dinosaure</span></a></span> this looks great! thanks for all of the hard work. Have you had to deal with porting much C code (Caml_ba_data_val vs. Bytes_val) ? Having a single slice abstraction for both sounds sensible. I had a go at porting Uring to bytes (ignore the moving in memory issue) and ended up with a copy of Cstruct using bytes (Bstruct!) <a href="https://github.com/patricoferris/ocaml-uring/blob/b43a8ee3a2b4117c50aa53ec20b5255edf5465c5/lib/uring/util.ml" target="_blank" rel="nofollow noopener" translate="no"><span class="invisible">https://</span><span class="ellipsis">github.com/patricoferris/ocaml</span><span class="invisible">-uring/blob/b43a8ee3a2b4117c50aa53ec20b5255edf5465c5/lib/uring/util.ml</span></a></p>
