I don't get your analogy, but (neo)vim is a full featured IDE if you configure it to be one

I adore my GPD Win Mini, they're the only ones putting out good pocketable clamshell devices and I adore them for it

Not even technically, actually. Wine and proton are translation layers that basically provide a dictionary of system calls so that Windows-specific ones can be translated to Linux calls instead

I also recommend folks check out Dyson Sphere Program, I've sunk many hundreds of hours into it at this point

My favorite variant: Your secret is safe with my indifference.

I think OP said training data, but meant recognition database. In a way, it's both, but they're talking about the same thing you are

I've been in tech since 2003 in some form or another, I'm right there with you in thinking XP feels recent. My daughter was 2 in 2018, so it's definitely felt super quick to me too.

You're correct in that it is a compatibility layer - And I'm not disagreeing with that. Also to be clear: Not just arguing to argue or trying to start a fight, mind you. I just find this to be an interesting topic of discussion. If you don't find it to be a fun thought experiment, feel free to shoo me away and I'll apologize and leave it alone.

That said, we appear to only be arguing semantics - Specifically around "native" having multiple contextual definitions:

• I am using 'native' to mean "the instructions are executed directly by the CPU, rather than through interpretation or emulation" ... which WINE definitely enables for Windows executables running on Linux. It's the reason why Proton/DXVK enables gaming with largely equal (and sometimes faster) performance: There is no interception of execution, there is simply provision of API endpoints. Much like creating a symlink in a directory where something expects it to be: tricking it into thinking the thing(s) it needs are where it expects them to be.

• However, you are using 'native' to mean "within the environment intended by the developer", and if that's the agreed definition then you're correct.

That's where this becomes an interesting thought experiment to me. It hits me as a very subjective definition for "native", since "within the intended environment" could mean a lot of things.

• Is that just 'within a system that provides an implementation of the Win32 API'? If so, WINE passes that test.
• If I provide an older/fixed/patched version of a DLL (by just placing it in the same directory) to fix an issue caused by a breaking change to a program that is running on Windows, is that no longer native?
• Or is it just ultimately that the machine must run the NT kernel, since that's where the developer intended for it to run?

Does that make sense? I hear a statement like that and I find myself wondering Which layer along the chain makes it "native"? - I find myself curious at what point the definition changes, in a "Ship of Theseus" kind of way.

It seems to me that if we agree that the above means "running in WINE is not native", then we must also agree that "anything written running for .NET (or any other framework, really) is not native", since .NET apps are written for the .NET framework (Which is not only officially available for Windows, mind you) and often don't include anything truly Windows-specific. Ultimately, both are providing natively-executed instructions that just translate API calls to the appropriate system calls under the hood.

I hope that does a better job of characterizing what I meant.

Gotta get one that slopes. Or 3D print a slope for yours.

I think it's supposed to be an option for ranked-choice or something.

Corrections:

1. They are not subdomains, they are just paths.

   A subdomain would be like programmer_humor.lemmy.world.

2. Communities exist on many instances, not just Lemmy.world

I've used Spotify since about 2012, and have been considering setting up some *arr instances at some point in the future to remedy that. Music discovery is just so much easier on something like Spotify though.