• 0 Posts
  • 10 Comments
Joined 2 years ago
cake
Cake day: November 23rd, 2023

help-circle

  • I think the problem with packaging isn’t so much that there aren’t good options. Some people don’t like Flatpak. Some people don’t like snaps. Maybe AppImage would be a good option. But these are all choices that can potentially fragment the target demographic even further, which reduces the value returned for the time invested in supporting it. Just my opinion, certainly not an expert.

    Wine is a great solution for windows-only things. The great thing about gaming, though, is that many of them are using languages like C++ which have full support on Linux systems natively. If you then have your graphics running through Vulkan, that also works across platforms. So, in my opinion, Wine shouldn’t be something we continue to need for gaming. Not saying Wine won’t be used or won’t continue to be useful for gaming, just that it doesn’t have to be the primary path to support Linux.


  • Are Linux ports of games so hard to do? Genuine question. I am not a games dev.

    My personal opinion is that Windows is an easier target because all Windows machines are consistent in their underlying interface with the user’s hardware. Same idea with MacOS. You know what display manager and graphics library to target, and what packaging format to target.

    Then, there’s Linux, which can be one of any number of distributions with varying software stacks, packaging formats, etc. It’s not that Linux gaming is radically difficult to support, it’s just much less standardized. This makes it a lot more work for a much smaller demographic. The Vulkan graphics API has made some of the software issues much less of a problem, but you still have to contend with things like different display managers and stuff like packaging differences between distributions.






  • Google is the only one that allows “End to end” encryption.

    Allowing and implementing are not the same things. They implemented encryption in their RCS services. They don’t allow everyone to use their service, but they built and own it so that’s their right, I guess.

    And practically speaking google controls the standard, they have over 800 million users out of the total possible 1.2 billion.

    Can you elaborate here? How do they control the standard? Specifically, I’m not asking about their implementation of RCS, because of course they control that, but their implementation is not the same thing as the standard itself.

    It might not be a monopolistic standard in theory but it is in practice

    It’s widely understood that it’s difficult to implement a competent web browser. That’s why there are only a handful of browser choices. This doesn’t make HTTP a monopolistic protocol.

    Saying the RCS standard is a monopolistic standard makes zero sense to me, even in practice. We are quite literally discussing another vendor entering the market. If you run a telecom and want to implement RCS, you are able to do so. If you are a phone manufacturer you are free to implement RCS in your software stack. None of this is easy, but it’s possible and so this isn’t a monopoly situation as far as I understand it. Google wanted to compete with iMessage so they built a competitor on a proprietary but open global standard, the standard which is meant to replace SMS and MMS messaging.