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.
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.
This is literally Computer 101. You should have backups. You should have off-site/cloud backups. And you shouldn't charge people for it.
If you don't, you are not a serious professional in *any* computer-based field. This is a basic industry standard requirement.
That's like saying "I charge my users for the prorated cost of the computer I bought".
This expense is part of doing business. It should be built into your cost structure.
And this isn't even just about the cmo3 business. Being able to provide files again to your clients in case *they* lose them is a minimum courtesy service. Yes the clients should have their own backups, but why wouldn't you provide a failsafe? You have backups anyway, right?
The only exception to this rule I can think of is for people working in areas with massive project files (video, think 100+GB per project). And even then you should be keeping stuff backed up for free for a time period and disclose this guarantee.
It is a genuine *tragedy* for people to be unable to update your model because you lost the file.
People's models are their identity. Losing access to it for updates is a tragedy and something I would say isn't far removed from medical malpractice.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
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.
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.
When you commission a 3D model, you may or may not get a raw .blend file, but whatever final model file can usually be re-imported for adjustments or changes and additions, and different models can be merged together into one.
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.
Live2D could easily fix this by allowing moc3 files to be imported into a new cmo3 file "as a black box", set up so that you can remove/hide ArtMeshes and build on the existing parameter inputs and physics settings, but not view/change the actual parameter rigs.
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.
TLDR Valorant isn't bricking anything, it just turns on a system security feature that makes these crazy fake NVMe drives stop working (because they don't follow the NVMe spec)... and I guess some people had Windows installed on them so it stops booting or something.
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 ^^;;
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!
All those things Rust has that Zig doesn't are important for the things I'm doing.
Destructors/RAII are fundamental to how the driver tracks and cleans up firmware structures safely and reliably when needed. If I had to write "defer" everywhere it would be a bug-prone mess...
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.
Reading upstreaming mailing list threads is painful. Every second comment is "why is this not like C" or "do it like C". Nobody is putting any effort into understanding why Rust exists and why it works. It's just superficial "this code is scary and foreign" type reactions.
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?
When a callback is called are any locks held or do you need to acquire your own? What about free callbacks, are they special? What's the intended locking order? Are there special cases where some operations might take locks in some cases but not others?