<p><span class="h-card" translate="no"><a href="https://mastodon.social/@gamingonlinux" class="u-url mention">@<span>gamingonlinux</span></a></span> I think EA&#39;s handling of Veilguard and their staff already had killed any enthusiasm I had for their products, but blocking Linux is pretty much the end for me. I love my Steam deck and being able to play on Linux desktop SO much.</p>

<p><span class="h-card" translate="no"><a href="https://chaos.social/@swetland" class="u-url mention">@<span>swetland</span></a></span> i just did 420 KB/s :3</p>

<p>the next step would be to make the FPGA manipulate 33-bit-reversed and 38-bit values instead of making PyPy suffer JITting that</p>

<p>i managed to get it to over 420 KB/s (that&#39;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&#39;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 &quot;perish&quot; option. However, it&#39;s no joke. I never wanted to play that dumb game--and frankly viewed ACM/IEEE as hostile. </p><p>Yeah, a &quot;yearly career exam&quot; 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&#39;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: `&#39;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&#39;s functor to avoid code duplication. In terms of performance, this is the best solution.</p>