> Yaak will add a plugin system to its closed-core model, achieving the benefits of open source without the burden.
In what world does having a plugin system even come close to achieving the benefits of open source?
> This means it's often quicker for the maintainer to just implement the feature themselves.
This is an argument to not take external PRs, but that doesn't require being closed source. For example, SQLite.
> Transparency doesn't just mean code, however. There are many ways for closed-source projects to be transparent as well.
But none of them are even close to as good. That's like saying you shouldn't ever wash your hands because there are many other ways to stop the spread of disease.
> It's possible for users to audit the code of an open-source project and disclose any issues. The key word here is "possible." I don't actually remember this happening
But "impossible" is strictly worse than "possible but hasn't yet happened to my knowledge".
> Imagine working at a company that hired anyone who applied. It would quickly fill with people bringing irrelevant experience and misaligned incentives. This is the unfortunate reality of open source
But that's not what open source is. That would only be if you had a bot that accepted every PR with no review.
> It's hard to deal with unappreciative or rude feedback
It's hard to manage long back-and-forth feedback cycles
It's hard to say no to most things once the project has matured
It's hard when a good contributor leaves
It's hard to feel good about 1000+ open issues
It's hard that it never stops.
But all of those things are also true of closed source software.
> Looks like you can set a password on it now, which is cool
I wish they didn't support that. There's not actually a security boundary there since you can't just reattach to another user's session anyway, and a lot of security people make stupid rules like "if something supports a password, you always have to use one".
This is fundamentally the wrong way to do anti-cheat. Anything you do on the client will fundamentally always be bypassable, and it tends to always have at least some negative side effects. Proper anti-cheat needs to happen on the server.
Doesn't work. Say, a shooter has support for surround/immersive audio - the client has to know where an approaching enemy is so that it can appropriately render footstep sounds or shadows. That in turn can be used by cheat aids to warn about someone sneaking up on you.
I don't think the situation is so clear-cut to be able to make categorical statements like that: server-side cheat prevention is also bypassable, and depending on how it is implemented, also has the potential for negative side effects. No matter what approach the developer takes, they're going to be making a trade-off of efficacy, player convenience, and developer effort, and that trade-off is going to be influenced by a lot of different things, such that client-side cheat prevention (or, likely, a mix of client-side and server-side measures) will be the most reasonable option in at least some circumstances.
It's not possible because the client's representation of the information from the server is an important part of the "gameplay". In typical network applications (that are not video games) the client's interpretation/representation of what the server is sending is entirely for the usability of the application. Maybe the client displays an array as text list, a series of cards, different tabs, etc. It's just about what makes sense to a particular client/user and what makes their life easier. It's not "unfair" for me to have an email client that highlights unread emails differently than you.
In a video game, different interpretations will give different people different, unfair, advantages. There is an "agreed upon" representation from the developer of the game that's supposed to be "fair" for everyone. Displaying audible ques as visual ques is a "cheat". Highlighting a piece of information or an object is a "cheat". Auto-interpreting information you're supposed to parse yourself is a "cheat". Not every cheat is God-Mode breaking-the-physics-of-the-game cheat. Plenty of cheats are just about having a slight edge over others.
For example, your game has a minimap. Part of the "gameplay" is that you scan the minimap every X seconds to check if something is approaching. It's a situational awareness skill that some will be better at than others. A flashing red map when something approaches would give you an edge. Or the server is sending spacial audio information about where a sound is coming from. It's an auditory skill that you develop and some will be better at it than others. An arrow on the screen pointing to where the audio is coming from would defeat that part of the game. Being able to see a moving shadow in the distance, or when to break/turn in a racing game, or an odds-calculator/card-counter in a cards game, a parry/counter attack indicator in a fighting game, etc are all "skills" that you are expected to develop to become "good" at this game. They are what make these games fun/rewarding for people. Having tools to help you with these tasks would be considered "cheats" in these games.
At the end of the day, there are "cheats" that no software can catch. Having a friend sit next to you who just watches the minimap, or who calculates stuff for you, or watch a different part of the screen for you are all "cheats" that no software can catch.
Obviously there is some stuff to be done to limit the "exploit-ability" of the information. Don't have the server send information that the client doesn't need like the location of all players all the time. Have the server reject invalid moves, like a player flying when there is no flying mechanics/ability for that player. But at the end of the day, the minimal amount of information needed to play the game can be exploited by someone if they find a different way to represent it to themselves that gives them an unfair advantage.
If that's a deal breaker, then what phone would you buy? Every Android phone supports FLAG_SECURE (which is such an Orwellian name), and iOS has its own equivalent API: https://github.com/JayantBadlani/ScreenShield
Well, the phone should keep my own needs above everything else, and no app maker should hamstring me on MY OWN phone. Somehow I have the feeling certain phone makers are sitting on the horse backwards.
I agree with you. I don't want app developers to stop me from being able to screenshot whatever I want on my own phone. I just don't know what to do about it.
There are too many apps tied to some real-world thing that only support iOS and Android. Consider banking apps for mobile check deposit, or apps that let you remote start your car. And even if you were willing to go without those conveniences, consider the SeatGeek app. I've been to shows where the only way to get tickets was with that app - there was no paper option and no Web option. And even though emulators like Waydroid exist, a lot of those kinds of apps implement things like SafetyNet or Play Integrity, basically to intentionally refuse to work in any environment not officially blessed by Google.
Depends on where you stand. I could always build GrapheneOS myself and enable root again but I just don't have any need for it and prefer the stronger security guarantees disabling root comes with.
Those licenses themselves aren't even sufficient to protect against this, since copyright holders don't have to follow their own licenses. To be fully safe from this kind of rug pull, the project also needs to accept substantial external contributions without a CLA, like the Linux kernel does.
Pretending to embrace open source while you're getting a foothold and then abandoning it as soon as you become successful isn't "maturing". It's pulling the ladder up behind you.
reply