• 0 Posts
  • 54 Comments
Joined 9 months ago
cake
Cake day: March 21st, 2024

help-circle
  • Kinda. It’s basically a love child between server hosting and streaming services with focus on gaming.

    You can connect your Steam account, for example, and then run games on their hardware which is streamed to you by browser. So you have control which games to run into but have to bring your own.

    Payment options include more powerful hardware but even the basic one was great when I used it. So I could play a modern game with raytracing on my old potato. Your machine just needs to be able to easily stream stuff, so run a modern browser without sweating.

    On the offside, it’s naturally always online and I had latency problems when many players were online which was common on weekends and what got me to upgrade my setup eventually.



  • Cleaning up files upon uninstall - Your uninstall script should already be cleaning up any files created or modified by your install process. However, we know that some older games may not fully remove files upon uninstall, and it isn’t possible to update the game any longer. Players need to know if any anti-cheat utilities have left files behind, especially those that modify OS kernel files.

    This section alone shows how stupid kernel level anti-cheat is. Play a game and gain a persistent security risk. It’s actually a feature that such games don’t run on Linux.



  • If you go back to my example, you’ll notice there is a UserUniqueValidator, which is meant to check for existence of a user.

    Oops, right, I just glanced over the code and obviously missed the text and code had different class names. Another smell in my opinion, choosing class names that only differ in the middle. Easily missed and confusion caused.

    I don’t think our opinions are too far off though. You’re just scaling the validation logic to realistic levels and I warn that in practice coders extrapolate too quickly and too often, which results in too much generic code which is naturally harder to understand and maintain than specific code.


  • I would argue that the validate routines be their own classes; ie UserInputValidator, UserPasswordValidator, etc.

    I wouldn’t. Not from this example anyway. YAGNI is an important paradigm and introducing plenty of classes upfront to implement trivial checks is overengineering typical for Java and the reason I don’t like it.

    Edit: Your naming convention isn’t the best either. I’d expect UserInputValidator to validate user input, maybe sanitize it for a database query, but not necessarily an existence check as in the example.