Afaik, LGPL means that the library has to remain dynamically linked. That’s it. No static linking is allowed and no embedding (i.e. hardcoding) is allowed unless also the outer project is also in a LGPL-compatible license.

So, no, they wouldn’t be legally allowed to steal your source by hardcoding it, if that’s what you are worried about.

The issue is with code and resources that cannot be dynamically linked. I called them “glue code”, that’s the stuff developers need, in order to use your library. That is not directly your library, but you will be shipping it with your library, most likely. You will need a different license for those resources, maybe MIT or even a public domain license such as CC0.

EDIT: I noticed you mentioned Steamworks SDK in another comment. I know Steam provides an optional DRM solution which wraps games in their own proprietary system. That might be forbidden by LGPL, I’m not sure. But linking an LGPL library to the same game that links to the proprietary Steamworks SDK shouldn’t be a problem, as long as the linking is dynamic and not static.

Why not LGPL the Rust code, and CC0 the glue code?

If your question is about the legal difference: this fork is licensed as GPL 2 (free libre open-source software), while the OG is proprietary (albeit source-available).

This means that everyone is allowed to do anything with this version and nobody can ever prevent them from doing so, while the OG doesn’t have such freedom.

The original authors might one day decide to halt the development and pull the source code, and/or decide to start “enshittifying” Aseprite, but LibreSprite will forever remain free and available to everyone.

For me it was the same drive. I remember I had to generate a special file to convince VirtualBox to use the physical partition as if it was part of a different drive. I don’t remember the details. Quite hacky perhaps, but it worked.

Iirc I had a Windows 7 (maybe 8 or 10) Home OEM, original (not cracked), but it still worked. Perhaps if I had kept using it for long periods in the VM it would have started complaining? Anyways I booted it baremetal from time to time, so maybe that’s why it kept working.

That would definitely be a technical challenge, but also it’s absolutely possible.

I used to do dual-boot Windows + Linux and I could run the Linux installation from a VM in Windows as well as the Windows installation from a VM in Linux.

When rebooting between metal and VM, Windows would always spend a few minutes “doing things” before continuing to boot, but it worked.

Linux would not even fret. It would just boot normally without any complaints.

I don’t remember exactly which distro I had at the time, but probably it was Linux Mint.

If you don’t want proprietary drivers the choice is quite straightforward: AMD. The official drivers are open source.

As for my experience, I’ve had absolutely no problems in the last few years with AMD, but I have to admit that I have always been using an iGPU, which has always been good enough for my needs.

I used to have problems with Nvidia proprietary drivers, but that was at least a couple years ago, things might have changed. I’ve never had issues with the free unofficial drivers, besides worse performance.

There’s the whitepaper.

https://github.com/deepseek-ai

Yeah, I realize that and that’s a nuisance for a videogame… If the game is small enough, OP might be able to give it a virtual GPU with VirtualBox, I did it in the past to play with friends on a single computer. I don’t know if the usual KVM-based VMs support it as well.

Keep in mind that non-hardenized containers only protect you from bugs, they don’t protect you from sophisticated malware. If you suspect the software you are trying to run might be a virus, don’t run it, or run it in a virtual machine.

I would recommend using containers only if you absolutely understand how to make them secure AND you have no reason to suspect the software you are running might contain nefarious code. In any other case use a virtual machine.

On Windows: VirtualBox (free and easy to use, but still advanced/powerful) or HyperV (already included if you have Windows Pro).

On Linux: anything based on KVM, my personal favourite is virt-manager, but QEMU is also great.

I would stay away from VMware because the free version is quite limited, and the pro version is not free. The free alternatives are equally good or better, so no reason to use something paid imho.

No no, this is actually open source. Not just the ISA, but also the silicon.

https://github.com/OpenXiangShan/XiangShan

I filled your survey. It would be nice if you could share the results once it’s completed.

Well… that would make sense. But it’s much much easier to just do it preemptively. The browser API to check how much memory is available are quite limited afaik. Also if there are too many elements the browser will have to do more work when interacting with the page (i.e. on every rendered frame), thus wasting slightly more power and in a extreme cases even lagging.

For what it’s worth, I, as a web developer, have done it too in a couple occasions (in my case it was absolutely necessary when working with a 10K × 10K table, way above what a browser is designed to handle).

Actually that might not have been done to deliberately disrupt your flow. Culling elements that are outside of the viewport is a technique used to reduce the amount of memory the browser consumes.

I would recommend checking out LosslessCut. Behind the curtain it runs ffmpeg, so you should be able to find the perfect command.

In the features list:

View ffmpeg last command log so you can modify and re-run modify recent commands on the command line

Official article about the incident: https://godotengine.org/article/statement-on-godloader-malware-loader/

We do have a federated GitHub alternative. Perhaps not too mature yet, but it does indeed exist. Forgejo

Let’s not forget Forgejo, a fork of Gitea. Self-hosted. It’s CodeBerg’s backend.

1099$, seriously? 😅