I've spent years playing with BWT and suffix sorting at school (some work can be found be names of archon and dark). It's a beautiful domain to learn!

Now I'm wondering: in the era of software 2.0, everything is figured out by AI. What are the chances AI would discover this algorithm at all?

No need to speculate about this algorithm in particular. It's been a few years since every programmer has had access to LLMs (that's a huge sample size!). Some LLMs are even branded as 'Research'. Plus they never get tired like humans do. We should be swimming in algorithms like this.

Shipping Vulkan in production on Linux is a challenge. Chrome was dealing with it for a while. Recently, with Zed ported to Vulkan, we saw the variety of half-broken platforms and user configurations.

I'd recommend Blended to not close the door on OpenGL and instead keeping it as a compatibility fallback.

> Recently, with Zed ported to Vulkan, we saw the variety of half-broken platforms and user configurations.

Thank you for sharing this! It'll be good to prevent others from following down the same path (my team included).

How is life at Zed? Have y'all raised capital in line with Windsurf / Cursor? Are you bootstrapping instead?

It's phenomenal that y'all are working natively in Rust rather than building on kludgy web tech.

I'm not employed by Zed, so I can't answer these questions. But the product itself is great!

Another option might be to write a D3D render backend for Blender and run that on top of DXVK on Linux (which is probably the most robust and most tested 3D rendering path on Linux thanks to Proton - with the assumption that DXVK contains tons of workarounds for various Vulkan driver problems that had been encountered in the wild by Proton).

on Linux it seems the direction is to drop the OpenGL drivers and run a compatibility layer on top of Vulkan.

Sure. Maybe that's the forcing function for them to nail down all the kinks. Example: https://github.com/kvark/blade/issues/205

Oh irony. The article talks about exaggerated attention to success of individuals, like Zuck, being an issue in Silicon Valley. And yet the article itself talks about this AI Ad direction as something invented by evil Zuck. This isn't really about Zuck. Ultra-convincing ads will happen soon regardless of what Zuck does.

Firefox rendering is based on WebRender, which runs on OpenGL. The internals of WebRender are similar to gpui but with significantly more stuff to cover the landscape of CSS.

Those rotifers might have inspired the 3-body problem's concept of dehydration/rehydration as a skill to survive cataclysms.

Don’t a lot of small organisms do this? Eg. “Sea monkeys” (brine shrimp)?

Tardigrades also do anhydrobiosis

David Baron was a distinguished engineer at Mozilla - not someone you fire at a whim. What makes you think he didn't leave voluntarily?

Super excited to see this reviving! We need more exploration into Linux structure: this world of hundreds distros barely different by their desktop environments - is too borong.

The gamedev ecosystem appears to be split between nalgebra (for Rapier users) and glam. Where does lin-alg fit?

There's also bevy_math with quite large number of crates depending on it.

bevy_math also uses glam, re-exported in the prelude: https://github.com/bevyengine/bevy/blob/cc69fdd0c63ea79fda4f...

cgmath?

cgmath is nice, but it uses old Rust 2015 and hasn't been updated since January 2021.

I can't imagine any obvious reason I would miss Rust's 2018 edition, let alone 2024 edition, to implement linear algebra? People seemed happy enough in Fortran before I was old enough to go to school and I don't sense it's an application where I'd want async for example. A lot of other edition changes are nice when writing new thing but not helpful for an existing codebase. So, like, sure, it's 2015 edition but that's fine?

There's actually an advantage to using older editions, and that is that it lowers the MSRV (minimum supported Rust version). This is especially nice for libraries, while binary project usually can just use the latest edition.

it's updated, just not on crates.io

In pinhole cameras, straight lines look straight. That's what a regular projection matrix gives you with rasterization. With non-pinhole cameras, straight lines look curved. You can't rasterize this directly. 3D Gaussian splats have an issue with this, addressed by methods like ray tracing. It's very useful to train on non-pinhole cameras, because in real world they can capture a wider field of view.

Locking DLSS-4 to 50xx only is unfortunate. I don't expect it to rely on any new superpowers. Otherwise - looks like a big step with the AI.