I've used LEB128 (with canonicalisation) extensively and... this looks so much nicer for most use-cases (length prefixed, supports the full uint64 range without that extra 10th byte).
The downside is the encoding size. LEB128 quickly grows to 2 bytes, but stays at 2 bytes all the way to 2^14. This is important if you're using these numbers as tags/identifiers as we were in the multicodec [1] project, or for network message lengths. bijou64 only gives you 500 <= 2 byte numbers.
I keep trying it (coming from EXWM) but I get lots of lag, stutters, and poor fractional scaling. I'm not sure how much of that is "GTK under wayland", Emacs's PGTK build (known to have lag/rendering issues), AMD kernel drivers (?), or EWM itself; but it's not yet a replacement for EXWM in my experience.
Have you tried enabling MTP? Those numbers are similar to what I was getting on my Strix Halo box, but configuring/enabling MTP doubled the TG speed of the 27B model (18-20 t/s now).
Features like the magic cursor look cool: an infinitely flexible context menu. However, context menus make it clear what you can and cannot do. If the magic cursor can't "do everything reasonable", it'll be just as usable as Siri.
I'd be more likely to believe them if they had already implemented this feature on their Pixel phones, but they haven't so I expect it probably isn't "done".
Nix and Lix daemon implementations are affected by buffer overflows vulnerabilities that allow a local attacker to gain arbitrary code execution as the daemon user (root in multi-user installations).
Box<str> is still two words (length and pointer). That's better than the 3 words (length, pointer, capacity) for strings, but Box<String> is one word (not including the heap allocation).
I've actually spent some time debugging why git causes so many issues with the backup software I use (restic).
Ironically, I believe you have it backwards: pack files, git's solution to the "too many tiny files" problem, are the issue here; not the tiny files themselves.
In my experience, incremental backup software works best with many small files that never change. Scanning is usually just a matter of checking modification times and moving on. This isn't fast, but it's fast enough for backups and can be optimized by monitoring for file changes in a long-running daemon.
However, lots of mostly identical files ARE an issue for filesystems as they tend to waste a lot of space. Git solves this issue by packing these small objects into larger pack files, then compressing them.
Unfortunately, it's those pack files that cause issues for backup software: any time git "garbage collects" and creates new pack files, it ends up deleting and creating a bunch of large files filled with what looks like random data (due to compression). Constantly creating/deleting large files filled with random data wreaks havoc on incremental/deduplicating backup systems.
My experience is that Emacs wants to be your everything, and works best if you let it. Have you tried putting your terminals inside of Emacs instead of the other way around?
I live in LA and Waymos are the only cars I don't have to play chicken with when crossing the street. Even the drivers that see you will just give you a "sorry, I'm in a rush" wave as they nearly run you over.
I've been using it for 2.5 years at this point, and have the same experience. I don't think it's hopeless, but Kagi will need to step up their methods. IMO, there's actually a lot they can do here.
Copyleft is a mirror of copyright, not a way to fight copyright. It grants rights to the consumer where copyright grants rights to the creator. Importantly, it gives the end-user the right to modify the software running on their devices.
Unfortunately, there are cases where you simply can't just "re-implement" something. E.g., because doing so requires access to restricted tools, keys, or proprietary specifications.
Maybe I've just lost all patience for fluff, but I gave up trying to figure out what the attack was from the article pretty quickly where the abstract answered all my questions immediately.
To prevent malicious Wi-Fi clients from attacking other clients on the same network, vendors have introduced client isolation, a combination of mechanisms that block direct communication between clients. However, client isolation is not a standardized feature, making its security guarantees unclear. In this paper, we undertake a structured security analysis of Wi-Fi client isolation and uncover new classes of attacks that bypass this protection. We identify several root causes behind these weaknesses. First, Wi-Fi keys that protect broadcast frames are improperly managed and can be abused to bypass client isolation. Second, isolation is often only enforced at the MAC or IP layer, but not both. Third, weak synchronization of a client’s identity across the network stack allows one to bypass Wi-Fi client isolation at the network layer instead, enabling the interception of uplink and downlink traffic of other clients as well as internal backend devices. Every tested router and network was vulnerable to at least one attack. More broadly, the lack of standardization leads to inconsistent, ad hoc, and often incomplete implementations of isolation across vendors. Building on these insights, we design and evaluate end-toend attacks that enable full machine-in-the-middle capabilities in modern Wi-Fi networks. Although client isolation effectively mitigates legacy attacks like ARP spoofing, which has long been considered the only universal method for achieving machinein-the-middle positioning in local area networks, our attack introduces a general and practical alternative that restores this capability, even in the presence of client isolation.
[1]: https://codeberg.org/ezemtsov/emacs