Okay, I generally side with *both* users and riggers because this cmo3 or not situation is mostly Live2D's fault but.

This has got to be the worst rigger take I've seen so far. If you can't afford to keep your clients' files safe by default, you should not be doing this job.

https://twitter.com/_AisCreme/status/2061300444601938430

If you do not provide a cmo3 to users, it is your absolute prerogative to make the utmost effort to never, ever lose those files.

There is no possible excuse for losing paid client work like that. Ever. Period. That's a hill I will die on. This is the lowest possible bar.

A lot of people aren't appreciating how weird and abnormal the Live2D situation is. Thread.

I make music. When I do a comm, the client can ask for stems, which allows them to remix or remaster the song part by part. I don't need to send them my project file and plugins.

https://twitter.com/Lina_Hoshino/status/2060992033049976838

When you commission model art, you don't get the raw working PSD file, the artist's brushes, or their editor settings, but you get a cleaned cut PSD file that can be rigged but also built upon for adjustments and additions if necessary.

I understand the riggers' perspective here because the project file has their workflow and settings; but

For a client, this is equivalent to buying a car you can't service or change any parts on. Right To Repair is a thing for good reason.

https://twitter.com/WynterpuppyVT/status/2060863157925793897

The bigger issue here is Live2D moc3 is a proprietary file format that has not had meaningful third party tooling/RE.

It's like the only options are you can't service your car at all, or the manufacturer gives you all their source code.

It doesn't have to be like this.

TIL people are using crazy FPGA DMA attack stuff to... cheat in games.

Back in my day this was a fun attack vector for things like BitLocker and other secure systems...

Also... $6k???? You can do this for a couple hundred max, someone is making BANK here.

https://twitter.com/AzakaSekai_/status/2057795814261752065

Kernel level anticheat is evil, but also, if you're running this kind of insane setup you kind of should expect it to stop working with any OS/driver update too.

If you're booting your OS from a fake evil noncompliant NVMe drive itself then... yeah you kind of had this coming.

Almost every thread about Rust for Linux ends up with someone saying "why not Zig instead"? And usually the answer is just "it's less mature" or "nobody pushed it".

I didn't know anything about Zig, so I decided to take a look today... and I'm not very impressed ^^;; I learned that Zig does not have:

- Destructors
- Macros
- Lifetimes
- Operator overloading

Those are major reasons why I chose Rust for the drm/asahi driver...

It sounds like Zig is trying to be "modern C"... but the whole point of R4L is to not get stuck with C!

Honestly, I'm kind of sad about Wedson leaving RfL. He developed a huge part of the foundation that made Rust for Linux possible.

I'll still work on DRM (except sched) and driver upstreaming when the core stuff is in place, but I don't know about other subsystems. At the rate things are going, I wouldn't be surprised if upstreaming the drm/asahi driver isn't possible until 2026 at the earliest. I had hopes for things to move much faster, but that's not possible without active cooperation from existing maintainers, and we aren't getting it.

I think people really don't appreciate just how incomplete Linux kernel API docs are, and how Rust solves the problem.

I wrote a pile of Rust abstractions for various subsystems. For practically every single one, I had to read the C source code to understand how to use its API. Simply reading the function signature and associated doc comment (if any) or explicit docs (if you're lucky and they exist) almost never fully tells you how to safely use the API. Do you need to hold a lock? Does a ref counted arg transfer the ref or does it take its own ref?

I regretfully completely understand Wedson's frustrations.



A subset of C kernel developers just seem determined to make the lives of the Rust maintainers as difficult as possible. They don't see Rust as having value and would rather it just goes away.lore.kernel.org/lkml/202408282… When I tried to upstream the DRM abstractions last year, that all was blocked on basic support for the concept of a "Device" in Rust. Even just a stub wrapper for struct device would be enough.

That simple concept only recently finally got merged, over one year later.

🎉🎉🎉 My Linux M1 GPU driver passes >99% of the dEQP-GLES2 compliance tests!!!!! 🎉🎉🎉

Most of this is thanks to @alyssarzg's prior work on macOS, but now I can replicate it on Linux! ^^ @alyssarzg Got some hints from Alyssa, now at 99.3%!

Hello everyone~! Stream starts in 2 hours!!

I'm honestly not too confident about this one... it feels like every time I look at the problem, it looks like something else! Maybe it's time to investigate some related issues and see if they shed any light on the issue? ^^;; Things that might be worth doing:
- Implement tracepoints for GPU stuff instead of printk
- Hook up GPU stats & ktrace to tracepoints
- Look closer at ASIDs
- Write the firmware heap allocator so we can stop leaking firmware objects as a workaround

There's a lot of weird debate about whether Rust in the kernel is useful or not... in my experience, it's way more useful than I could've ever imagined!

I went from 1st render to a stable desktop that can run run games, browsers, etc. in about two days of work on my driver (!!!) All the concurrency bugs just vanish with Rust! Memory gets freed when it needs to be freed! Once you learn to make Rust work with you, I feel like it guides you into writing correct code, even beyond the language's safety promises. It's seriously magic! ✨

Thank you to everyone who watched my XDC2022 talk with @alyssarzg!! I hoped you liked my new witch hat, drawn by the amazing @nana_nono120!🧙‍♀️🪄

We did the whole talk on an M1 Mac Mini running my Rust kernel driver and Alyssa's Mesa driver, using Firefox and @Inochi2D on GNOME!🚀 I'll be keeping the hat on for at least all of October, so make sure to drop by my dev streams if you want to see more of it!! ✨✨

Coming up next, let's see if we can finally work out that pesky TLB invalidation issue!!!!

🦀🐧🍎🔻🧊🇼👩🔥🦊⚙️

Neverball, Firefox + YouTube, and @Inochi2D, in a GNOME Wayland session!!!

All running at the same time, on an Apple M1 Mac Mini with my Rust Linux kernel driver and @alyssarzg's Mesa driver for the M1 GPU!!!

🦀🐧🍎🔻🧊🇼👩🔥🦊⚙️
▶️ For those who haven't been following, I didn't paste myself on top!! That's Inochi2D running my avatar in real time on the desktop session (with a transparent window background)!

Spending the time before the stream making GitHub CI work and fixing Clippy warnings 😊 I really like these! I knew these floats had garbage digits (caused by a round-trip through Python where they became doubles), but I wasn't expecting Rust to help me fix it!

I had a crazy issue with place!() that had me chasing a NULL pointer dereference for a long time... it was a really, really weird corner case!!!

Read on for a crazy Rust unsoundness story 🦀 place!() is a crazy macro I've been developing over the past few days to work around the lack of placement new in Rust. 🤔

It basically takes a pointer and what looks like a struct initializer (even with nested structs!), and then writes each field and sub-field one by one.