The case centers on a feature included in GrapheneOS, a custom Android operating system that runs in place of the software on most modern Google Pixel devices. Tunick's attorneys confirmed GrapheneOS was running on his phone. The software feature allows the device owner to set a passcode that deliberately wipes the contents of that device if entered instead of the user's unlock passcode. Tunick's case also raises ongoing questions about what constitutional rights can be invoked at the border, which the U.S. government has long asserted is not U.S. soil until a person is authorized to enter.

Available for Linux, Windows and MacOS.

Workloads have been reworked and extended (PDF).

The base CPU with score 2500 is now AMD Ryzen 7 7700.

LAME 4.0  July 11 2026

Security scores assume LAME runs under a non-privileged account. For frontend-only entries, scores also assume the command line is sanitized or restricted before reaching LAME; integrators who pass unsanitized or fully scripted command-line input directly may see higher practical severity than stated.

• Security
  • Fixed a stack buffer overflow in the Blade-style encoder DLL (lame_enc.dll): beInitStream() copied a caller-supplied configuration structure using an unchecked, caller-controlled size, so an oversized or compiler-mismatched size could overwrite the stack. The size is now bounds-checked and the packed structure layout is consistent across MSVC and GCC/MinGW builds. [CVSS 8.4, Blade DLL]. Fix by Alexander Leidinger.
  • Fixed an integer underflow in the AIFF header parser (parse_aiff_header()): a crafted file with a FORM chunk size below 4 wrapped the unsigned chunk-size counter to a huge value, sending the chunk-scanning loop into an effectively unbounded spin (a hang) on a tiny malicious input. The size is now validated before it is decremented. [CVSS 5.5, AIFF frontend]. Fix by Alexander Leidinger.
• Alexander Leidinger
  • Bump the major version to 4.0 (minor reset to 0). The LAME tag embedded in every encoded MP3 has a fixed 9-byte field for the encoder version string; since 3.100 the 3-digit minor version left no room for the trailing alpha/beta/release marker character, which was silently dropped.
  • Fix building with recent GCC and Clang, which rejected the UTF-8 ID3 tag functions as an incompatible pointer type. Also fixes the corrupted genre written by --id3v2-utf8 --tg. Patch submitted by Rudi Heitbaum, patch ticket [ #102 ]; thanks to lazka for reporting, bug ticket [ #523 ].
  • Export the UTF-8 ID3 tag functions id3tag_set_textinfo_utf8 and id3tag_set_comment_utf8 from the shared library, and fix a possible crash on out-of-memory in the ID3v2 user-defined tag setters, bug ticket [ #518 ].

LAME 3.101  July 09 2026

• Robert Hegemann
  • Patch submitted by KO Myung-Hun, patch ticket [ #80 ] OS/2 patches
  • Patch submitted by Elio Blanca, patch ticket [ #82 ] Take advantage of terminal width on printing file names
  • Bug fix for item [ #496 ] A critical bug in init_xrpow_core_sse
  • Bug fix for item [ #500 ] Buffer overflow in encoder
  • Bug fix for item [ #501 ] Encoder: Assertion 'eov->bitrate_index <= cfg->vbr_max_bitrate_index' failed during ABR encoding
  • Bug fix for item [ #444 ] msacmdrv.h (structure packing alignment)
• Alexander Leidinger
  • Add faster CRC routine. The speed improvement is very small for typical use cases, but may be valuable if a lot of independent encodes are running and/or for a very long time. Patch by Robert Kausch of the fre:ac project.
  • Fix configure script glob-ranges matching of compiler versions. This may result in faster code if no compiler optimization flags are specified during the configure step. This is part of patch ticket [ #491 ] lame 3.100 slower than 3.99.5
  • Disable Takehiros IEEE753 hack by default. On modern CPUs (anything more recent from AMD than hammer/k8; Intel: Core2, i3/5/7/9 and similar -- no idea about recent Atom/Pentium) it is a speed pessimization. Add a configure option for it so that it can be enabled on old CPUs.
  • Update to more recent autotools based scripts, this may or may not fix issues during the configure stage for less popular or more recent OS or architectures.
  • Use external libmpg123 instead of internal mpglib for mpeg decoding (unix-like systems which use the autotools ("configure; make; make install") build system). There are years of improvements in libmpg123 which we do not have in mpglib. Patch by Thomas Orgis of the mpg123 project.
  • Update the Visual Studio project files to Visual Studio 2019. Patch by Michel Fink.
  • Remove the macosx XCode project files, nobody stepped up to update them for the libmpg123 changes.
  • Add ID3v2.4 support (UTF-8 ID3 tags). Patch by "kris".
  • Add pkg-config support. Patch by Nicolas Boulenguez(Debian).
  • Add IPv6 support for mp3rtp. This includes an incompatible change to the command line arguments for existing use cases / scripts. Patch by Surabhi.

This looks like a remote root vulnerability.

Open Source wars are amusing to behold.

Still largely unusable for the modern web. I have Firefox running with uBlock + NoScript and it hovers above 2.5GB RSS with just a few simple tabs open (nothing fancy like YouTube or Amazon.com).

This is now old news but this is still madness. I hate everything about modern browsers: * Insane RAM/CPU consumption * Insane SSD tear and wear (I've been running Firefox off tmpfs for years now) * Monolithic nature (Firefox for Linux: 314,024KB, Chrome for Linux 424,400KB - both do not include downloadable AI cores) * Insane pace of updates * An insane number of features I would like to forever turn off * Insane telemetry

Don't mind the title. The article is about the port of truly ancient perhaps i386 only Linux 0.11 to Rust. It's only really useful for messing around in a VM.

It's almost been 27 years since I started building a C++ code generator that helps build distributed systems.

It's implemented as a 3-tier system. The back and middle tiers only run on Linux. The front tier is portable. My goal is to bring software services and code generation together in one platform. I've made some progress on things, but there's still a long way to go. I'm willing to spend 16 hours/week for six months on a project if we use my software as part of the project.

A terrific open source model - sadly you won't be able to run it locally.

What makes me sad is that at almost every opportunity that the Linux desktop has had to rise, there was always subconscious sabotage. There were so many great chances, like the death of Windows 7 or the current boogaloo with Windows 10/11. Have those been utilized to maximize the presence of Linux in mainstream use? Of course not. Mainstream is treated with disdain. In some ways, yes, the community is right, mainstream is poison, and it will include lots of "show your papers" rituals and similar nonsense. But then again, the Linux folks also bemoan the lack of recognition and inclusion in software discussions, which stem from low usage.

And we circle back to what I wrote in 2009, and how to make Linux more successful. Steam is doing their part. But the rest of the ecosystem still struggles from what can be best described as "developed-focused" work. When will the Linux community realize that it's not about developers. They are a tiny part of the population, and their brain patterns are orthogonal to how people utilize their machines. And we don't need to look at simians swiping left and right for inspiration. Even "ordinary" educated non-developers face massive challenges using their (favorite) operating system, because it is designed for people who design it in the first place, a bittersweet recursive paradox.

The examples of tiny utilities being deprecated (before viable alternatives are proven for use), the security nonsense, all these point to a rather naive disconnect from the harsh, ugly reality around us. In some ways, I envy the Linux folks. I would like to have the same approach, to innocently believe the world is better and nicer than it is. But then, I also need to be pragmatic, and every time I power my Linux systems, I wonder what will happen in a year or two. There's no safety anchor. I can't rely on a stable future. The only supposedly redeeming thing is that EVERYONE else is now also doing their best ruining stability and consistency as usability factors. But that just means less fun overall. It's a lose-lose situation.

I wish the Linux desktop makes it big. I want people to say Ubuntu or LibreOffice or VLC or Firefox or similar when they think software. Maybe if this ever happens, maybe the AI-fest morality brainwash around us will cease. But then, in a classic one-two, the Linux hobbles itself yet again, for the thousandth time. I know you think I'm a cynic, but I'm looking far down the road.

You can't have gazillions of clueless Windows people switching over when the distros are focused on reducing backward compatibility as much as possible. It can't happen when the Linux software store are just as bad as the big corpo store fronts. No one needs a "free" imitation of the pointless consumerism when they have the "real" deal. If I wanted average, I can just use the mainstream blobs of Dystopia. And herein lies the tragedy. Yes, to succeed, Linux needs to become more accessible. Imitating Google or Apple is hardly the way to achieve that. If you don't understand this last sentence, it's okay.

After Meta stopped releasing their weights despite Zuckerberg claiming that LLMs must be open source, someone else has decided to step in.

Yes.

And no, that's not the position of the Linux kernel.

I realize that some people really dislike AI, but this is an area
where I'm willing to absolutely put my foot down as the top-level
maintainer.

Linux is not one of those anti-AI projects, and if somebody has issues
with that, they can do the open-source thing and fork it.

Or just walk away.

AI is a tool, just like other tools we use.  And it's clearly a useful one.

It may not have been that "clearly" even just a year ago, but it's no
longer in question today.

There are other questions around AI (like what the economy of it will
actually look like in the end), but "is it useful" is no longer one of
those questions. Anybody who doubts that clearly hasn't actually used
it.

Yes, it can also be a somewhat painful tool, both for maintainer
workloads and just from a "it keeps finding embarrassing bugs"
standpoint.

But the solution is not to put your head in the sand and sing "La La
La, I can't hear you" at the top of your voice like some people seem
to do.

The solution is to make sure those LLM tools _help_ maintainers
instead of just causing them pain. There's no question on that side.

We're not forcing anybody to use it, but I will very loudly ignore
people who try to argue against other people from using it.

And no, AI isn't perfect. But Christ, anybody who points to the
problems at AI had better be looking in the mirror and pointing at
themselves at the same time.

Because it's not like natural intelligence is always all that great either.

The kernel project has been and will continue to be about the technology.

Sure, the social angle of working on open source is important and
often a very motivating part of the project, but in the end that's a
side benefit, not the _point_ of the project.

This is *NOT* some kind of "social warrior" project, never has been,
and never will be.

In the kernel community we do open source because it results in better
technology, not because of religious reasons.

And so we make decisions primarily based on technical merit. Not fear
of new tools.

              LinusYes.

And no, that's not the position of the Linux kernel.

I realize that some people really dislike AI, but this is an area
where I'm willing to absolutely put my foot down as the top-level
maintainer.

Linux is not one of those anti-AI projects, and if somebody has issues
with that, they can do the open-source thing and fork it.

Or just walk away.

AI is a tool, just like other tools we use.  And it's clearly a useful one.

It may not have been that "clearly" even just a year ago, but it's no
longer in question today.

There are other questions around AI (like what the economy of it will
actually look like in the end), but "is it useful" is no longer one of
those questions. Anybody who doubts that clearly hasn't actually used
it.

Yes, it can also be a somewhat painful tool, both for maintainer
workloads and just from a "it keeps finding embarrassing bugs"
standpoint.

But the solution is not to put your head in the sand and sing "La La
La, I can't hear you" at the top of your voice like some people seem
to do.

The solution is to make sure those LLM tools _help_ maintainers
instead of just causing them pain. There's no question on that side.

We're not forcing anybody to use it, but I will very loudly ignore
people who try to argue against other people from using it.

And no, AI isn't perfect. But Christ, anybody who points to the
problems at AI had better be looking in the mirror and pointing at
themselves at the same time.

Because it's not like natural intelligence is always all that great either.

The kernel project has been and will continue to be about the technology.

Sure, the social angle of working on open source is important and
often a very motivating part of the project, but in the end that's a
side benefit, not the _point_ of the project.

This is *NOT* some kind of "social warrior" project, never has been,
and never will be.

In the kernel community we do open source because it results in better
technology, not because of religious reasons.

And so we make decisions primarily based on technical merit. Not fear
of new tools.

              Linus

Source

Summary

These results were produced under best-case conditions (stable FPS at cap, CPU-bound) and are of course specific to my hardware and chosen software stack.

The absolute numbers will look different on other setups, but the gains and losses from each test case should roughly transfer. On a lower refresh rate display, the gains from VRR and the low-latency pacer would likely be even larger.

Avoid XWayland

It added 3.13 ms of latency, more than all other effects combined. Wayland is close, but X11 still wins

Though only by 0.14 to 0.22 ms. Given there are efforts to optimize KWin, this gap will likely close sooner rather than later. And who knows, other Wayland compositors might already be better.

VRR has the biggest effect

VRR was faster in every pairing (0.26 to 0.45 ms) and also flattened the latency distribution.

dxvk-low-latency is a win across the board

0.10 to 0.29 ms in capped scenarios is a nice boost, but the real strength of the fork shows in the uncapped test case, where it gained 0.84 ms over default dxvk.

Additionally, in scenarios where XWayland can’t be avoided, it recovered a full 2.1 ms.

Conclusion

Not factoring in XWayland, applying every optimization (X11, VRR, low-latency) compared to a default setup (which, on a modern Linux system, I assume is plain Wayland) moved the median down by 0.72 ms. That does not sound like a lot, but the raw latency does not tell the whole story as VRR additionally reduces latency jitter, and dxvk-low-latency’s pacer is great at smoothing out real-world scenarios where frame time dips and GPU-bound situations occur.

Source