• 83 Posts
  • 686 Comments
Joined 8 months ago
cake
Cake day: February 10th, 2024

help-circle
  • as said in computer science it has accepted by most people (for the sake of having categories) that CPU emulation is emulation, and otherwise its not.

    It’s important to keep in mind that things said in computer science for the sake of having categories are usually said within the very narrow implicit context of a particular field of study, like microprocessor design. It makes sense there for the sake of brevity, just as arcane acronyms make sense when everyone in the room understands what they stand for in that context. But the context no longer applies when we’re out in the rest of the world using a word that is not so narrowly defined, as we are now.

    I think we mostly agree, because you pointed this out yourself:

    It’s a “domain specific” language; which means, you have to specify it before in order to make use.

    However, I want to clarify my position in response to this:

    nobody has the right to act like having a clear definition and saying anyone else is wrong.

    I often encounter people on social media chiding or mocking others for referring to Wine as an emulator, which is disheartening for a number of reasons. Importantly, the people reading such comments are being taught that it’s wrong to call Wine an emulator, when in fact it is not wrong at all. Wine’s very purpose is to emulate. This is plainly visible not just in how it is used, but also in how it is developed (many of its behaviors are reverse engineered Windows behaviors, departing from the API docs) and how it functions (it does a heck of a lot more than translating system calls).

    The Wine project’s FAQ acknowledges the misunderstanding, a bit indirectly, by pointing out that it is “more than just an emulator”.

    Unfortunately, since most people in the discussions I mentioned have no visibility into Wine’s internals, they don’t know any better than to accept what they were told by multiple people on the internet. They are misled by a smug few who love to tell others they’re wrong by repeating that officially abandoned slogan that was never really true (at least not in the context that framed it) in the first place. And then some of the misled people adopt it themselves, so we end up with more of the “you’re wrong” attitude, perpetuation of a ridiculously narrow understanding of the word, and people who publish about the topic performing awkward linguistic gymnastics to avoid simply saying “emulator” for fear of rebuke.

    I think all three of those results make the world a little worse, so I’m here to let everyone reading know that it’s perfectly appropriate to call Wine (or Proton) an emulator. Anyone who claims it’s wrong to do so is perhaps a hardware field specialist who has lost sight of the importance of context in language, or (more likely) either honestly mistaken or an internet troll.


  • Hardware is not the only thing that can be emulated. Here’s an example. To claim that things emulating software components are not emulators is simply incorrect, like claiming that squares are not rectangles. It’s always disappointing to see someone spreading that falsehood.

    It’s true that Wine is not a hardware emulator, nor is Proton. But make no mistake: they are both emulators.

    The unfortunate backronym made a kind of sense 20 years ago. At the time, lawsuits were flying hard and fast at projects offering APIs and tools modeled after commercial operating systems (Unix variants), and there was no established case law protecting them. The prospect of Wine contributors getting sued into oblivion by Microsoft was a very plausible threat. Rebranding it as “Wine Is Not an Emulator” helped frame it as something different as it grew and gained attention, and although that phrase is inaccurate, “Wine Is Not a Hardware Emulator” wouldn’t have fit the existing name or distanced it from being seen as a Windows work-alike. Also, most emulators of the time happened to be hardware emulators, so it didn’t seem like a terribly big stretch.

    That time is gone, though. The legal standing for software based on reverse engineering is more clear than it was then. Microsoft has not sent its lawyers after our favorite runtime emulator. The backronym was thankfully abandoned by the project some years ago. Weirdly, there are still people on social media spreading false statements about what the word does and doesn’t mean.



  • This is not enshittification.

    Enshittification refers to a process with specific phases that ensure services will degrade at the expense of users, and then business customers, so that shareholders can extract as much profit as possible from both of those groups. It was coined by Cory Doctorow, who explains it here:

    Here is how platforms die: First, they are good to their users; then they abuse their users to make things better for their business customers; finally, they abuse those business customers to claw back all the value for themselves. Then, they die.

    I call this enshittification, and it is a seemingly inevitable consequence arising from the combination of the ease of changing how a platform allocates value, combined with the nature of a “two-sided market,” where a platform sits between buyers and sellers, hold each hostage to the other, raking off an ever-larger share of the value that passes between them.






  • There are a few JeOS distros out there, usually built around something like Kodi or Jellyfin. I’ve had good experiences with LibreELEC, which (through Kodi) can do audio and video files, broadcast TV, live streams, VOD channels, and even game emulators if the hardware can handle them. It works well on small devices.

    When choosing hardware, beware of the fractional frame rate issue: Lots of TV content has a video frame rate that’s a little bit off from the whole numbers usually expected by computers, like 30000/1001 = 29.97002997 fps instead of 30 fps. Support for these frame rates is missing from a lot of systems-on-chip, so small media boxes that use them will have to fake it by dropping or duplicating frames every so often. The result is not smooth.

    All the Raspberry Pi models that I’ve checked do support fractional frame rates, so that would be a pretty safe hardware choice.













  • I don’t remember the statement in the bug report verbatim, but it indicated that they intend to fix it, which is about what I had previously seen on other issues that they did subsequently fix. I expect it’s mainly a matter of prioritizing a long to-do list.

    I can’t think of a reason why it wouldn’t be possible. The protocol is continually evolving, after all, and they already moved message content to an encrypted channel that didn’t originally exist. Moving other events into it seems like a perfectly sensible next step in that direction.