Sometimes I listen to music without lyrics like surf or gabber. Other times its genre music like northern soul or punk or familiar music where the lyrics are so familiar or vacuous/cliche that they don't distract. I wouldn't listen to really lyrically focussed music like singer songwriter stuff generally. So I think there's a spectrum rather than just instrumental music vs everything else.
I think this is correct and projects like DuckDB are doing a food job at supporting both halves by triaging issues also based on the identity and affiliation of the author (no anonymous issues) and converting them into supporters https://duckdblabs.com/community_support_policy/
This passive approach of libxml2 where the software remains community only is just fine and totally fair, but corporate users can pay up if there's a clear offering. What they actually get doesn't need to be much, but if it does need to be clear. Of course this does change the project into hybrid community/corperate open source but there can be a spectrum there where a lot of time and resources is carved out for the community approach and the corperate sponsors are given just enough to keep them happy. In a way some more corperate focussed Linux distributions are also an example of a hybrid approach really given the two worlds are very much linked.
Almost definitely. You can think of there being a type of triangle inequality for cascading different systems where manually combined systems almost always perform worse given comparable data and model capacity. Alternatively you have tied the models hands by forcing it to bottleneck through a representation you chose.
> Because box86 uses the native versions of some “system” libraries, like libc, libm, SDL, and OpenGL, it’s easy to integrate and use with most applications, and performance can be surprisingly high in some cases.
I'm not sure you can run Wine natively to run x86 Windows programs on RISC-V because Wine is not an emulator. There is an ARM port of Wine, but that can only run Windows ARM programs, not x86.
It should be theoretically possible to build Wine so that it provides the x86_64 API while compiling it to ARM/RISCV. Your link doesn't make it clear if that's what's being done or not.
(Although I suspect providing the API of one architecture while building for another is far easier said than done. Toolchains tend to be uncooperative about such shenanigans, for starters.)
Box64's documentation is just on installing the Wine x64 builds from winehq repos, because most arm repos aren't exactly hosting x64 software. It's even possible to run Steam with their x64 Proton running Windows games. At least on ARM, not sure about RISC-V.
> As Wine Is Not an Emulator, all those applications can't run on other architectures with Wine alone.
Or do you mean provide the x86_64 Windows API as a native RISC-V/ARM to the emulator layer? That would require some deeper integration for the emulator, but that's what Box64/box86 already does with some Linux libraries: intercept the api calls and replace them with native libraries. Not sure if it does it for wine
> but that's what Box64/box86 already does with some Linux libraries: intercept the api calls and replace them with native libraries. Not sure if it does it for wine
Yeah, that's what I meant. It's simple in principle, after all: turn an AMD64 call into an ARM/RISCV call and pass it to native code.
Doing that for Wine would be pretty tricky (way more surface area to cover, possible differences between certain Win32 arch-specific structs and so forth) so I bet that's not how it works out of the box, but I couldn't tell for sure by skimming through the box64 repo.
