Google Rust crate audits are now open source: https://opensource.googleblog.com/2023/05/open-sourcing-our-rust-crate-audits.html
Web developers: when you say, “your browser does not support this site,” what you REALLY mean is that YOU don’t support the browser. Don’t turn it around on the user because you chose not to stick to well-supported standards, or worse, are doing user agent sniffing.
If you truly use some feature shipped by one browser and not everyone, at least say, “We use x standard feature, which is unsupported in this browser.” But even then, the web is all about progressive enhancement.
🔥 Introducing telephoto, a compose library for displaying zoomable images with automatic sub‑sampling of large bitmaps: https://saket.github.io/telephoto/
A bit of (simplified) X history and how we got here.
Back in the 90s and 2000s, X was running display drivers directly in userspace. That was a terrible idea, and made interop between X and the TTY layer a nightmare. It also meant you needed to write X drivers for everything. And it meant X had to run as root. And that if X crashed it had a high chance of making your whole machine unusable.
Then along came KMS, and moved modesetting into the kernel. Along with a common API, that obsoleted the need for GPU-specific drivers to display stuff. But X kept on using GPU-specific drivers. Why? Because X relies on 2D acceleration, a concept that doesn't even exist any more in modern hardware, so it still needed GPU-specific drivers to implement that.
The X developers of course realized that modern hardware couldn't do 2D any more, so along came Glamor, which implements X's three decades of 2D acceleration APIs on top of OpenGL. Now you could run X on any modern GPU with 3D drivers.
And so finally we could run X without any GPU-specific drivers, but since X still wants there to be "a driver", along came xf86-video-modesetting, which was supposed to be the future. It was intended to work on any modern GPU with Mesa/KMS drivers.
That was in 2015. And here's the problem: X was already dying by then. Modesetting sucked. Intel deprecated their GPU-specific DDX driver and it started bitrotting, but modesetting couldn't even handle tear-free output until earlier this year (2023, 8 whole years later). Just ask any Intel user of the Ivy Bridge/Haswell era what a mess it all is. Meanwhile Nvidia and AMD kept maintaining their respective DDX drivers and largely insulating users from the slow death of core X, so people thought this was a platform/vendor thing, even though X had what was supposed to be a platform-neutral solution that just wasn't up to par.
And so when other platforms like ARM systems came around, we got stuck with modesetting. Nobody wants to write an X DDX. Nobody even knows how outside of people who have done it in the past, and those people are burned out. So X will *always* be stuck being an inferior experience if you're not AMD or Nvidia, because the core common code that's supposed to handle it all just doesn't cut it.
On top of that, ARM platforms have to deal with separate display and render devices, which is something modesetting can't handle automatically. So now we need platform-specific X config files to make it work.
And then there's us. When Apple designed the M1, they decided to put a coprocessor CPU in the display controller. And instead of running the display driver in macOS, they moved most of it to firmware. That means that from Linux's point of view, we're not running on bare metal, we're running on top of an abstraction intended for macOS' compositor. And that abstraction doesn't have stuff like vblank IRQs, or traditional cursor planes, and is quite opinionated about pixel formats and colorspaces. That all works well with modern Wayland compositors, which use KMS abstractions that are a pretty good match for this model (it's the future and every other platform is moving in this direction).
But X and its modesetting driver are stuck in the past. It tries to do ridiculous things like draw directly into the visible framebuffer instead of a back buffer, or expect there to be a "vblank IRQ" even though you don't need one any more. It implements a software fallback for when there is no hardware cursor plane, but the code is broken and it flickers. And so on. These are all problems, legacy nonsense, and bugs that are part of core X. They just happen to hurt smaller platforms more, and they particularly hurt us.
That's not even getting into fundamental issues with the core X protocol, like how it can't see the Fn key on Macs because Macs have software Fn keys and that keycode is too large in the evdev keycode table, or how it only has 8 modifiers that are all in use today, and we need one more for Fn. Those things can't be properly fixed without breaking the X11 protocol and clients.
So no, X will never work properly on Asahi. Because it's buggy, it has been buggy for over 8 years, nobody has fixed it in that time, and certainly nobody is going to go fix it now. The attempt at having a vendor-neutral driver was too little too late, and by then momentum was already switching to Wayland. Had continued X development lasted long enough to get modesetting up to par 8 years ago, the story with Asahi today would be different. But it didn't, and now here we are, and there is nothing left to be done.
So please, use Wayland on Asahi. You only get a pass on using X if you need accessibility features that aren't in Wayland yet.
Licensee 1.7.0 was released: https://github.com/cashapp/licensee/releases/tag/1.7.0
New features include the use of Maven's own pom parsing library which adds support for substitution variables, the ability to create custom license validation tasks on your own configurations, and support for the Gradle configuration cache.
Turbine 0.13.0 was released: https://github.com/cashapp/turbine/releases/tag/0.13.0
This brings support for six new Kotlin/Native targets thanks to the added support by kotlinx.coroutines. The coroutine dependency bump also brought stabilization of all but one of the experimental APIs that Turbine uses internally.
Onward towards 1.0.
In our first episode back to talking #AndroidDev shop on @fragmented we chat with my good friend and (ex)colleague @colin who helps us make sense of Square’s bold take on Compose!
Wild: “In January 2022, the system leaked 14% of all its gas into the atmosphere – the highest leak rate ever recorded by the utility in a month. In the past four years, the system leaked between 4 and 6% of its total supply each year, according to city data.”
Back when Danger was in stealth mode, pre-launch, the website just showed a random teaser flash animation. I found the SWF files and through the magic of WASM and something called Ruffle (ruffle.rs), you can now experience these in all their rotoscoped glory!
Updates on Android Performance at I/O:
Introducing dex layout optimizations with startup profiles, and the new Baseline Profiles Gradle plugin that automates your baseline profile workflows end to end.
10 years ago we launched two IntelliJ plugins as part of our first "Seven Days of Open Source" series.
At the time, Google was all-in on Eclipse and ADT. Square had always used IntelliJ for its Android apps thanks to Bob Lee's Java roots.
I posted the announcement to G+, as one did, and found it odd when @xav +1'd it. Five days later at I/O 2013 Android Studio was announced as the new IntelliJ-based IDE for Android.
Happy 10th, Android Studio.
Kier and I's "Modern Compose Architecture with Circuit" talk from #KotlinConf is finally up!
Having finally finished the Dune 2 & 3 books, I get to enjoy the treat that is the second installment of the early 2000s Sci-Fi miniseries which covers them. It has horrifically dated CGI and takes shockingly little liberties on the bonkers source material. It is somehow both not good, and also very good.
The video of my KotlinConf talk "Playing in the Treehouse with Redwood and Zipline" is now available!
This server is a place for Jake Wharton. Are you Jake Wharton? This is your place. Are you not Jake Wharton? Well, at least you can find him here.